diff mbox series

kbuild: Allow DTB overlays to built from .dtso named source files

Message ID 20221014151302.27641-1-afd@ti.com
State New
Headers
Series kbuild: Allow DTB overlays to built from .dtso named source files |

Commit Message

Andrew Davis Oct. 14, 2022, 3:13 p.m. UTC 
  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.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 scripts/Makefile.lib | 3 +++
 1 file changed, 3 insertions(+)

Comments

Rob Herring Oct. 20, 2022, 10:47 p.m. UTC | #1 
On Fri, Oct 14, 2022 at 10:13 AM Andrew Davis <afd@ti.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.

Rob
Geert Uytterhoeven Oct. 21, 2022, 6:52 a.m. UTC | #2 
Hi Rob,

On Fri, Oct 21, 2022 at 12:47 AM Rob Herring <robh+dt@kernel.org> wrote:
> On Fri, Oct 14, 2022 at 10:13 AM Andrew Davis <afd@ti.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?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
Andrew Davis Oct. 21, 2022, 2:44 p.m. UTC | #3 
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@kernel.org> wrote:
>> On Fri, Oct 14, 2022 at 10:13 AM Andrew Davis <afd@ti.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?

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.

Thanks,
Andrew
Rob Herring Oct. 21, 2022, 4:59 p.m. UTC | #4 
On Fri, Oct 21, 2022 at 9:44 AM Andrew Davis <afd@ti.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@kernel.org> wrote:
> >> On Fri, Oct 14, 2022 at 10:13 AM Andrew Davis <afd@ti.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
diff mbox series

Patch

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 3aa384cec76b..0376a6f18bfb 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -408,6 +408,9 @@  $(obj)/%.dtb: $(src)/%.dts $(DTC) $(DT_TMP_SCHEMA) FORCE
 $(obj)/%.dtbo: $(src)/%.dts $(DTC) FORCE
 	$(call if_changed_dep,dtc)
 
+$(obj)/%.dtbo: $(src)/%.dtso $(DTC) FORCE
+	$(call if_changed_dep,dtc)
+
 dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
 
 # Bzip2