[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAL_JsqL0zG9_sthMLKMEWjYzBdSDwjJ1D6SsZr3CDe3w8mKE+g@mail.gmail.com>
Date: Fri, 21 Oct 2022 11:59:22 -0500
From: Rob Herring <robh+dt@...nel.org>
To: Andrew Davis <afd@...com>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Nishanth Menon <nm@...com>,
Vignesh Raghavendra <vigneshr@...com>,
Masahiro Yamada <masahiroy@...nel.org>,
Michal Marek <michal.lkml@...kovi.net>,
Nick Desaulniers <ndesaulniers@...gle.com>,
devicetree@...r.kernel.org, linux-kbuild@...r.kernel.org,
linux-kernel@...r.kernel.org, Frank Rowand <frowand.list@...il.com>
Subject: Re: [PATCH] kbuild: Allow DTB overlays to built from .dtso named
source files
On Fri, Oct 21, 2022 at 9:44 AM Andrew Davis <afd@...com> wrote:
>
> On 10/21/22 1:52 AM, Geert Uytterhoeven wrote:
> > Hi Rob,
> >
> > On Fri, Oct 21, 2022 at 12:47 AM Rob Herring <robh+dt@...nel.org> wrote:
> >> On Fri, Oct 14, 2022 at 10:13 AM Andrew Davis <afd@...com> wrote:
> >>> Currently DTB Overlays (.dtbo) are build from source files with the same
> >>> extension (.dts) as the base DTs (.dtb). This may become confusing and
> >>> even lead to wrong results. For example, a composite DTB (created from a
> >>> base DTB and a set of overlays) might have the same name as one of the
> >>> overlays that create it.
> >>>
> >>> Different files should be generated from differently named sources.
> >>> .dtb <-> .dts
> >>> .dtbo <-> .dtso
> >>>
> >>> We do not remove the ability to compile DTBO files from .dts files here,
> >>> only add a new rule allowing the .dtso file name. The current .dts named
> >>> overlays can be renamed with time. After all have been renamed we can
> >>> remove the other rule.
> >>
> >> There was a patch from Geert converting everything. I'd rather not
> >> support both ways.
> >
> > Actually that was a patch from Frank?
> >
>
> That series looks to have stalled?
Feel free to resurrect it if Frank is not going to.
>
> It won't be easy to convert all the files in one go, especially with series
> in-flight with both names, not sure how we avoid having both extensions for
> at least one cycle. Plus having both allowed lets rename the existing files
> in a more granular/bisectable way.
Fair enough. I'd propose a series adding the build support and
converting the unittest. Then I can provide a branch for arm-soc and
the dts conversions.
Rob
Powered by blists - more mailing lists