From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C71ABC433DB for ; Mon, 11 Jan 2021 16:14:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8D45522BED for ; Mon, 11 Jan 2021 16:14:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388227AbhAKQOW (ORCPT ); Mon, 11 Jan 2021 11:14:22 -0500 Received: from mail.kernel.org ([198.145.29.99]:46020 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733195AbhAKQOV (ORCPT ); Mon, 11 Jan 2021 11:14:21 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 10E4322B30; Mon, 11 Jan 2021 16:13:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610381620; bh=Urfi7MuRhpUGvVyUz/7tHdR5Pc8foT1YLXVK04grcPw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FUkxZVko6R4B8OZL/LcJ4ziS9Rg3RtGjxiuL/FwgtkuQJuEK82TqdoD9P43saVScv AVlA41qIFoegqW+caPtCCEBnWNUI1AhvgaapeEpufBVqOW2bvBlCoTFeq1fCjUJdY/ j8dCTQ74YRR/roq4poMVd+iY+GK3PxLNYIT2u+vWve/+nCVHKAVRlgWUocj8YFMNdl urXh48m2JtDsb//ysP2avRfTahHCmwamaPHj6nncN4geoj8Tr6oqPMcB0Ds8Sz5h47 ZDd5ASM14XnkoMXhnPUEEi+ECqZw4PzA3yy4baaATIC7Ug2ipFwsfhKE0IPFD03z3c HKUOdkaSM2ofQ== Received: by mail-ed1-f47.google.com with SMTP id i24so279343edj.8; Mon, 11 Jan 2021 08:13:39 -0800 (PST) X-Gm-Message-State: AOAM533BO+5NTUdeJUlcjdwSECo538bGLkLerfei8cvaXpZFVMh55he7 gf2b6p5Kuq//slrQjGm8JINbEJRN/n/UG41T9Q== X-Google-Smtp-Source: ABdhPJw3c24e6XlhnbwSziA36wFuxQ1NccGshiVNtFSYA/nBEpCNmyhnpRmoijksjLsuhy3dxE3S9ZYziuy47Kt4DkA= X-Received: by 2002:aa7:d154:: with SMTP id r20mr106799edo.258.1610381618452; Mon, 11 Jan 2021 08:13:38 -0800 (PST) MIME-Version: 1.0 References: <20210111111711.r2xesydzhq5js2nf@vireshk-i7> In-Reply-To: From: Rob Herring Date: Mon, 11 Jan 2021 10:13:24 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 0/2] kbuild: Add support to build overlays (%.dtbo) To: Masahiro Yamada , David Gibson , Viresh Kumar Cc: Arnd Bergmann , Olof Johansson , Pantelis Antoniou , Frank Rowand , Michal Marek , DTML , "linux-kernel@vger.kernel.org" , Linux Kbuild mailing list , Vincent Guittot , Bill Mills , tero.kristo@gmail.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +David Gibson On Mon, Jan 11, 2021 at 9:40 AM Masahiro Yamada wrote: > > On Mon, Jan 11, 2021 at 8:17 PM Viresh Kumar wrote: > > > > On 07-01-21, 14:28, Masahiro Yamada wrote: > > > Viresh's patch is not enough. > > > > > > We will need to change .gitignore > > > and scripts/Makefile.dtbinst as well. > > > > > > In my understanding, the build rule is completely the same > > > between .dtb and .dtbo > > > As Rob mentioned, I am not sure if we really need/want > > > a separate extension. > > > > > > A counter approach is to use an extension like '.ovl.dtb' > > > It clarifies it is an overlay fragment without changing > > > anything in our build system or the upstream DTC project. > > > > By the time you gave feedback, I have already sent the dtbo change for > > DTC to the device-tree-compiler list (based on Rob's suggestion). > > > > And it got merged today by David: > > > > https://github.com/dgibson/dtc/commit/163f0469bf2ed8b2fe5aa15bc796b93c70243ddc > > > > Can we please finalize what we need to do with naming here and be done > > with it, so I can rework my patches and get going ? > > > > Thanks. > > > > -- > > viresh > > > > It is unfortunate to see such a patch merged > before getting agreement about how it should work > as a whole. Given the feedback that dtbo is already a standard, I'd suggest we just stick with dts->dtbo. > >+# enable creation of __symbols__ node > >+ifneq ($(dtbo-y),) > >+DTC_FLAGS += -@ > >+endif > > I am not convinced with this code. > > A single user of the dtbo-y syntax gives -@ to all > device trees in the same directory. > > This is not a solution since Rob already stated -@ should be > given per board (or per platform, at least). Agreed. > I still do not understand why adding the new syntax dtbo-y > is helpful. I think we should stick with 'dtb-y' here. > Have we already decided to use separate ".dtb" and ".dtbo" for blobs? > > Will we use ".dts" for all source files? > Or, will we use ".dtso" for overlay source files? > > How should the build system determine the targets > that should have -@ option? The way it does already. Either: DTC_FLAGS += -@ in a directory of dts files. Or on a per file basis like: DTC_FLAGS_foo_base += -@ > For consistency, will we need a patch like follows? > > > diff --git a/dtc.c b/dtc.c > index bdb3f59..474401e 100644 > --- a/dtc.c > +++ b/dtc.c > @@ -120,6 +120,8 @@ static const char *guess_type_by_name(const char > *fname, const char *fallback) > return fallback; > if (!strcasecmp(s, ".dts")) > return "dts"; > + if (!strcasecmp(s, ".dtso")) > + return "dts"; > if (!strcasecmp(s, ".yaml")) > return "yaml"; > if (!strcasecmp(s, ".dtb")) > @@ -349,6 +351,8 @@ int main(int argc, char *argv[]) > > if (streq(outform, "dts")) { > dt_to_source(outf, dti); > + else if (streq(outform, "dtso")) { > + dt_to_source(outf, dti); > #ifndef NO_YAML > } else if (streq(outform, "yaml")) { > if (!streq(inform, "dts")) > > > > Overall solution looks unclear to me. > > > Again, it is unfortunate that we did not take enough time > (in spite of the RFC prefix) before proceeding. I should have added David here from the start. Honestly, I expected some discussion there. Rob