Re: [RFC PATCH 0/1] Categorize ARM dts directory

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Daniel Palmer]

Hi Ansuel

On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <ansuelsmth@gmail.com> wrote:
>
> Hi,
> as the title say, the intention of this ""series"" is to finally categorize
> the ARM dts directory in subdirectory for each oem.

While I agree with this change and think it's for the good (browsing
the ARM dts directory at the moment is frustrating..) I think
buildroot and others need to be told about this as it'll potentially
break their kernel build scripting for ARM and probably messes up the
configs they have for existing boards.

>  arch/arm/boot/dts/mstart/Makefile             |   10 +
>  .../mstar-infinity-breadbee-common.dtsi       |    0
>  .../mstar-infinity-msc313-breadbee_crust.dts  |    0
>  .../{ => mstart}/mstar-infinity-msc313.dtsi   |    0
>  .../boot/dts/{ => mstart}/mstar-infinity.dtsi |    0
>  .../mstar-infinity2m-ssd201-som2d01.dtsi      |    0
>  ...nfinity2m-ssd202d-100ask-dongshanpione.dts |    0
>  .../mstar-infinity2m-ssd202d-miyoo-mini.dts   |    0
>  .../mstar-infinity2m-ssd202d-ssd201htv2.dts   |    0
>  .../mstar-infinity2m-ssd202d-unitv2.dts       |    0
>  ...sd202d-wirelesstag-ido-sbc2d06-v1b-22w.dts |    0
>  ...ity2m-ssd202d-wirelesstag-ido-som2d01.dtsi |    0
>  .../mstar-infinity2m-ssd202d.dtsi             |    0
>  .../mstar-infinity2m-ssd20xd.dtsi             |    0
>  .../dts/{ => mstart}/mstar-infinity2m.dtsi    |    0
>  .../mstar-infinity3-msc313e-breadbee.dts      |    0
>  .../{ => mstart}/mstar-infinity3-msc313e.dtsi |    0
>  .../dts/{ => mstart}/mstar-infinity3.dtsi     |    0
>  .../mstar-mercury5-ssc8336n-midrived08.dts    |    0
>  .../{ => mstart}/mstar-mercury5-ssc8336n.dtsi |    0
>  .../boot/dts/{ => mstart}/mstar-mercury5.dtsi |    0
>  arch/arm/boot/dts/{ => mstart}/mstar-v7.dtsi  |    0

s/mstart/mstar/

Cheers,

Daniel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Tony Lindgren]

Hi,

* Daniel Palmer <daniel@0x0f.com> [220328 08:53]:
> Hi Ansuel
> 
> On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <ansuelsmth@gmail.com> wrote:
> >
> > Hi,
> > as the title say, the intention of this ""series"" is to finally categorize
> > the ARM dts directory in subdirectory for each oem.
> 
> While I agree with this change and think it's for the good (browsing
> the ARM dts directory at the moment is frustrating..) I think
> buildroot and others need to be told about this as it'll potentially
> break their kernel build scripting for ARM and probably messes up the
> configs they have for existing boards.

Yeah.. And ideally this would be done in smaller steps as these will
conflict with all the other pending patches.

For example, I have a pile of pending omap clock clean-up dts patches
posted and tested waiting for v5.19-rc1 to apply. I'd rather not start
redoing or fixing up the patches with sed :)

What I'd like to have see is that at some point when suitable we move
one machine at a time with a script if possible.. Maybe the dtb files
generated would need to remain in the current directory until all of
the machine dts files are moved? That should help with the build
scripting too probably :)

In general I like the idea though and I think we should do it.

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Andrew Jeffery]

On Tue, 29 Mar 2022, at 18:23, Tony Lindgren wrote:
> Hi,
>
> * Daniel Palmer <daniel@0x0f.com> [220328 08:53]:
>> Hi Ansuel
>> 
>> On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <ansuelsmth@gmail.com> wrote:
>> >
>> > Hi,
>> > as the title say, the intention of this ""series"" is to finally categorize
>> > the ARM dts directory in subdirectory for each oem.
>> 
>> While I agree with this change and think it's for the good (browsing
>> the ARM dts directory at the moment is frustrating..) I think
>> buildroot and others need to be told about this as it'll potentially
>> break their kernel build scripting for ARM and probably messes up the
>> configs they have for existing boards.
>
> Yeah.. And ideally this would be done in smaller steps as these will
> conflict with all the other pending patches.
>
> For example, I have a pile of pending omap clock clean-up dts patches
> posted and tested waiting for v5.19-rc1 to apply. I'd rather not start
> redoing or fixing up the patches with sed :)
>
> What I'd like to have see is that at some point when suitable we move
> one machine at a time with a script if possible.. Maybe the dtb files
> generated would need to remain in the current directory until all of
> the machine dts files are moved? That should help with the build
> scripting too probably :)

There's probably some reason not to, but could we symlink the new paths 
in the subdirectories to the existing files to handle the transition? 
Then do the move to remove the symlinks at some future point.

Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Geert Uytterhoeven]

Hi Tony,

On Tue, Mar 29, 2022 at 10:03 AM Tony Lindgren <tony@atomide.com> wrote:
> * Daniel Palmer <daniel@0x0f.com> [220328 08:53]:
> > On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <ansuelsmth@gmail.com> wrote:
> > > as the title say, the intention of this ""series"" is to finally categorize
> > > the ARM dts directory in subdirectory for each oem.
> >
> > While I agree with this change and think it's for the good (browsing
> > the ARM dts directory at the moment is frustrating..) I think
> > buildroot and others need to be told about this as it'll potentially
> > break their kernel build scripting for ARM and probably messes up the
> > configs they have for existing boards.
>
> Yeah.. And ideally this would be done in smaller steps as these will
> conflict with all the other pending patches.
>
> For example, I have a pile of pending omap clock clean-up dts patches
> posted and tested waiting for v5.19-rc1 to apply. I'd rather not start
> redoing or fixing up the patches with sed :)

Git merge/rebase/cherry-pick should handle renames fine?

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Tony Lindgren]

* Geert Uytterhoeven <geert@linux-m68k.org> [220329 09:02]:
> On Tue, Mar 29, 2022 at 10:03 AM Tony Lindgren <tony@atomide.com> wrote:
> > For example, I have a pile of pending omap clock clean-up dts patches
> > posted and tested waiting for v5.19-rc1 to apply. I'd rather not start
> > redoing or fixing up the patches with sed :)
> 
> Git merge/rebase/cherry-pick should handle renames fine?

Possibly.. Not sure I'd count on that based on my earlier experiences
though :)

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Matthias Brugger]

On 29/03/2022 11:54, Tony Lindgren wrote:
> * Geert Uytterhoeven <geert@linux-m68k.org> [220329 09:02]:
>> On Tue, Mar 29, 2022 at 10:03 AM Tony Lindgren <tony@atomide.com> wrote:
>>> For example, I have a pile of pending omap clock clean-up dts patches
>>> posted and tested waiting for v5.19-rc1 to apply. I'd rather not start
>>> redoing or fixing up the patches with sed :)
>>
>> Git merge/rebase/cherry-pick should handle renames fine?
> 
> Possibly.. Not sure I'd count on that based on my earlier experiences
> though :)
> 

Yes. If this could be split up in per silicon-vendor patches, the maintainer 
could take them. Although it might be a pain to soc maintainers to resolve small 
conflicts when merging that branches.

Just my 5 cents.

Matthias

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Nicolas Ferre]

Ansuel, All,

On 28/03/2022 at 10:55, Daniel Palmer wrote:
> Hi Ansuel
> 
> On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <ansuelsmth@gmail.com> wrote:
>>
>> Hi,
>> as the title say, the intention of this ""series"" is to finally categorize
>> the ARM dts directory in subdirectory for each oem.
> 
> While I agree with this change and think it's for the good (browsing
> the ARM dts directory at the moment is frustrating..) I think
> buildroot and others need to be told about this as it'll potentially
> break their kernel build scripting for ARM and probably messes up the
> configs they have for existing boards.

This aspect mustn't be underestimated and I anticipate lots of issues 
during a long time on this particular topic of "build systems".

Another aspect is CI and public or private testing farms we all have 
running.

These aspects always refrained me to change anything in the naming 
scheme of our DT files, but if we go in this direction, we must really 
be prepared and I'm still not convince it's worth it...


If this has to happen, I would also like to queue some file name changes 
to do all modifications in one go in order to lower the annoyance level 
of those who would need to adapt to those changes.

BTW, is there a common scheme for dts/dtsi file naming? Is it more 
enforced in one way or another for arm64 in a sense that I can take some 
norm as an example?

[..]

Best regards,
   Nicolas



-- 
Nicolas Ferre

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Robin Murphy]

On 29/03/2022 9:50 am, Nicolas Ferre wrote:
> Ansuel, All,
> 
> On 28/03/2022 at 10:55, Daniel Palmer wrote:
>> Hi Ansuel
>>
>> On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <ansuelsmth@gmail.com> wrote:
>>>
>>> Hi,
>>> as the title say, the intention of this ""series"" is to finally 
>>> categorize
>>> the ARM dts directory in subdirectory for each oem.
>>
>> While I agree with this change and think it's for the good (browsing
>> the ARM dts directory at the moment is frustrating..) I think
>> buildroot and others need to be told about this as it'll potentially
>> break their kernel build scripting for ARM and probably messes up the
>> configs they have for existing boards.
> 
> This aspect mustn't be underestimated and I anticipate lots of issues 
> during a long time on this particular topic of "build systems".
> 
> Another aspect is CI and public or private testing farms we all have 
> running.

Yet another is if this affects what `make dtbs_install` does (I don't 
know for sure, but I'd be inclined to suspect it might). Some distros 
use that to deliver the DTBs as part of their kernel package, so if 
paths suddenly change it could break end users' bootloader setups too.

Thanks,
Robin.

> These aspects always refrained me to change anything in the naming 
> scheme of our DT files, but if we go in this direction, we must really 
> be prepared and I'm still not convince it's worth it...
> 
> 
> If this has to happen, I would also like to queue some file name changes 
> to do all modifications in one go in order to lower the annoyance level 
> of those who would need to adapt to those changes.
> 
> BTW, is there a common scheme for dts/dtsi file naming? Is it more 
> enforced in one way or another for arm64 in a sense that I can take some 
> norm as an example?
> 
> [..]
> 
> Best regards,
>    Nicolas
> 
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH RFC 1/1] ARM/arm64: categorize dts in arm dir and fix dependency in arm64

[Geert Uytterhoeven]

 	Hi Ansuel,

On Mon, 28 Mar 2022, Ansuel Smith wrote:
> - Categorize every dts in arm directory in subdirectory
> - Fix Makefile to address for the arm subdirectory
> - Fix any arm64 dependency
>
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>

Thanks for your patch!

> --- /dev/null
> +++ b/arch/arm/boot/dts/renasas/Makefile

s/renasas/renesas/

The actual split for the Renesas parts LGTM.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 1/1] ARM/arm64: categorize dts in arm dir and fix dependency in arm64

[Jesper Nilsson]

Hi Ansuel,

On Mon, Mar 28, 2022 at 02:09:15AM +0200, Ansuel Smith wrote:
> - Categorize every dts in arm directory in subdirectory
> - Fix Makefile to address for the arm subdirectory
> - Fix any arm64 dependency
> [...]
>  arch/arm/boot/dts/axix/Makefile               |    3 +
>  .../boot/dts/{ => axix}/artpec6-devboard.dts  |    0
>  arch/arm/boot/dts/{ => axix}/artpec6.dtsi     |    0

All ARTPEC platforms should be in a directory called "axis".
Otherwise LGTM.

Thanks!

/^JN - Jesper Nilsson
-- 
               Jesper Nilsson -- jesper.nilsson@axis.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 1/1] ARM/arm64: categorize dts in arm dir and fix dependency in arm64

[Ansuel Smith]

On Mon, Mar 28, 2022 at 10:28:58AM +0200, Jesper Nilsson wrote:
> Hi Ansuel,
> 
> On Mon, Mar 28, 2022 at 02:09:15AM +0200, Ansuel Smith wrote:
> > - Categorize every dts in arm directory in subdirectory
> > - Fix Makefile to address for the arm subdirectory
> > - Fix any arm64 dependency
> > [...]
> >  arch/arm/boot/dts/axix/Makefile               |    3 +
> >  .../boot/dts/{ => axix}/artpec6-devboard.dts  |    0
> >  arch/arm/boot/dts/{ => axix}/artpec6.dtsi     |    0
> 
> All ARTPEC platforms should be in a directory called "axis".
> Otherwise LGTM.
> 
> Thanks!
> 
> /^JN - Jesper Nilsson
> -- 
>                Jesper Nilsson -- jesper.nilsson@axis.com

Will do the change! Noted.

-- 
	Ansuel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Linux-stm32] [RFC PATCH 1/1] ARM/arm64: categorize dts in arm dir and fix dependency in arm64

[Patrice CHOTARD]

Hi Ansuel

On 3/28/22 02:09, Ansuel Smith wrote:
> - Categorize every dts in arm directory in subdirectory
> - Fix Makefile to address for the arm subdirectory
> - Fix any arm64 dependency
> 
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>

>  create mode 100644 arch/arm/boot/dts/st/Makefile
>  rename arch/arm/boot/dts/{ => st}/spear1310-evb.dts (100%)
>  rename arch/arm/boot/dts/{ => st}/spear1310.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st}/spear1340-evb.dts (100%)
>  rename arch/arm/boot/dts/{ => st}/spear1340.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st}/spear13xx.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st}/spear300-evb.dts (100%)
>  rename arch/arm/boot/dts/{ => st}/spear300.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st}/spear310-evb.dts (100%)
>  rename arch/arm/boot/dts/{ => st}/spear310.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st}/spear320-evb.dts (100%)
>  rename arch/arm/boot/dts/{ => st}/spear320-hmi.dts (100%)
>  rename arch/arm/boot/dts/{ => st}/spear320.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st}/spear320s.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st}/spear3xx.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st}/spear600-evb.dts (100%)
>  rename arch/arm/boot/dts/{ => st}/spear600.dtsi (100%)


All SPEAr device tree should go into stm sub-directory, as this platform is a STMicroelectronics one
as STi or STM32.

Thanks

Patrice

>  create mode 100644 arch/arm/boot/dts/st_ericsson/Makefile
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ab8500.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ab8505.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-db8500.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-db8520.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-db9500.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-dbx5x0-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-dbx5x0.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-ab8500.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-family-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-stuib.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-tvk1281618-r2.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-tvk1281618-r3.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href520-tvk.dts (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefprev60-stuib.dts (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefprev60-tvk.dts (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefprev60.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefv60plus-stuib.dts (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefv60plus-tvk.dts (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefv60plus.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-nhk15.dts (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-s8815.dts (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-stn8815.dtsi (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-snowball.dts (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-codina.dts (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-gavini.dts (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-golden.dts (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-janice.dts (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-kyle.dts (100%)
>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-skomer.dts (100%)
>  create mode 100644 arch/arm/boot/dts/stm/Makefile
>  create mode 120000 arch/arm/boot/dts/stm/armv7-m.dtsi
>  rename arch/arm/boot/dts/{ => stm}/st-pincfg.h (100%)
>  rename arch/arm/boot/dts/{ => stm}/stih407-b2120.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stih407-clock.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stih407-family.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stih407-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stih407.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stih410-b2120.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stih410-b2260.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stih410-clock.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stih410-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stih410.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stih418-b2199.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stih418-b2264.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stih418-clock.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stih418.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stihxxx-b2120.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32429i-eval.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32746g-eval.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32f4-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32f429-disco.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32f429-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32f429.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32f469-disco.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32f469-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32f469.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32f7-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32f746-disco.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32f746-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32f746.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32f769-disco.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32f769-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32h7-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32h743.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32h743i-disco.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32h743i-eval.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32h750.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32h750i-art-pi.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp13-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp131.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp133.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp135.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp135f-dk.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp13xc.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp13xf.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp15-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp151.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp153.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp153c-dhcom-drc02.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-avenger96.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-dhcor-avenger96.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-dk1.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1-ctouch2-of10.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1-ctouch2.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1-edimm2.2.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-iot-box.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-microgea-stm32mp1-microdev2.0.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-microgea-stm32mp1.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-stinger96.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-stinger96.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-dhcom-pdk2.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-dhcom-picoitx.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-dk2.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-ed1.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-emsbc-argon.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-emstamp-argon.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-ev1.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-lxa-mc1.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-odyssey-som.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-odyssey.dts (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xc.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-drc02.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-pdk2.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-picoitx.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-som.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcor-avenger96.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcor-io1v8.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcor-som.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dkx.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-osd32.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxaa-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxab-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxac-pinctrl.dtsi (100%)
>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxad-pinctrl.dtsi (100%)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Linux-stm32] [RFC PATCH 1/1] ARM/arm64: categorize dts in arm dir and fix dependency in arm64

[Patrice CHOTARD]

On 3/28/22 11:09, Patrice CHOTARD wrote:
> Hi Ansuel
> 
> On 3/28/22 02:09, Ansuel Smith wrote:
>> - Categorize every dts in arm directory in subdirectory
>> - Fix Makefile to address for the arm subdirectory
>> - Fix any arm64 dependency
>>
>> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> 
>>  create mode 100644 arch/arm/boot/dts/st/Makefile
>>  rename arch/arm/boot/dts/{ => st}/spear1310-evb.dts (100%)
>>  rename arch/arm/boot/dts/{ => st}/spear1310.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st}/spear1340-evb.dts (100%)
>>  rename arch/arm/boot/dts/{ => st}/spear1340.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st}/spear13xx.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st}/spear300-evb.dts (100%)
>>  rename arch/arm/boot/dts/{ => st}/spear300.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st}/spear310-evb.dts (100%)
>>  rename arch/arm/boot/dts/{ => st}/spear310.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st}/spear320-evb.dts (100%)
>>  rename arch/arm/boot/dts/{ => st}/spear320-hmi.dts (100%)
>>  rename arch/arm/boot/dts/{ => st}/spear320.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st}/spear320s.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st}/spear3xx.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st}/spear600-evb.dts (100%)
>>  rename arch/arm/boot/dts/{ => st}/spear600.dtsi (100%)
> 
> 
> All SPEAr device tree should go into stm sub-directory, as this platform is a STMicroelectronics one
> as STi or STM32.

Just got an internal discussion, all STMicroelectronics platform should go into "st" sub-directory, and not in "stm" as indicated in my previous e-mail. ;-)

Patrice

> 
> Thanks
> 
> Patrice
> 
>>  create mode 100644 arch/arm/boot/dts/st_ericsson/Makefile
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ab8500.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ab8505.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-db8500.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-db8520.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-db9500.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-dbx5x0-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-dbx5x0.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-ab8500.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-family-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-stuib.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-tvk1281618-r2.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-tvk1281618-r3.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href520-tvk.dts (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefprev60-stuib.dts (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefprev60-tvk.dts (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefprev60.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefv60plus-stuib.dts (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefv60plus-tvk.dts (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefv60plus.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-nhk15.dts (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-s8815.dts (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-stn8815.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-snowball.dts (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-codina.dts (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-gavini.dts (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-golden.dts (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-janice.dts (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-kyle.dts (100%)
>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-skomer.dts (100%)
>>  create mode 100644 arch/arm/boot/dts/stm/Makefile
>>  create mode 120000 arch/arm/boot/dts/stm/armv7-m.dtsi
>>  rename arch/arm/boot/dts/{ => stm}/st-pincfg.h (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stih407-b2120.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stih407-clock.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stih407-family.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stih407-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stih407.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stih410-b2120.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stih410-b2260.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stih410-clock.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stih410-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stih410.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stih418-b2199.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stih418-b2264.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stih418-clock.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stih418.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stihxxx-b2120.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32429i-eval.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32746g-eval.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32f4-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32f429-disco.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32f429-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32f429.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32f469-disco.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32f469-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32f469.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32f7-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32f746-disco.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32f746-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32f746.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32f769-disco.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32f769-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32h7-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32h743.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32h743i-disco.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32h743i-eval.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32h750.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32h750i-art-pi.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp13-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp131.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp133.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp135.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp135f-dk.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp13xc.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp13xf.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp151.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp153.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp153c-dhcom-drc02.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-avenger96.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-dhcor-avenger96.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-dk1.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1-ctouch2-of10.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1-ctouch2.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1-edimm2.2.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-iot-box.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-microgea-stm32mp1-microdev2.0.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-microgea-stm32mp1.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-stinger96.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-stinger96.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-dhcom-pdk2.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-dhcom-picoitx.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-dk2.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-ed1.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-emsbc-argon.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-emstamp-argon.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-ev1.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-lxa-mc1.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-odyssey-som.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-odyssey.dts (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xc.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-drc02.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-pdk2.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-picoitx.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-som.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcor-avenger96.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcor-io1v8.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcor-som.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dkx.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-osd32.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxaa-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxab-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxac-pinctrl.dtsi (100%)
>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxad-pinctrl.dtsi (100%)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Linux-stm32] [RFC PATCH 1/1] ARM/arm64: categorize dts in arm dir and fix dependency in arm64

[Ansuel Smith]

On Mon, Mar 28, 2022 at 11:20:00AM +0200, Patrice CHOTARD wrote:
> 
> 
> On 3/28/22 11:09, Patrice CHOTARD wrote:
> > Hi Ansuel
> > 
> > On 3/28/22 02:09, Ansuel Smith wrote:
> >> - Categorize every dts in arm directory in subdirectory
> >> - Fix Makefile to address for the arm subdirectory
> >> - Fix any arm64 dependency
> >>
> >> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > 
> >>  create mode 100644 arch/arm/boot/dts/st/Makefile
> >>  rename arch/arm/boot/dts/{ => st}/spear1310-evb.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st}/spear1310.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st}/spear1340-evb.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st}/spear1340.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st}/spear13xx.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st}/spear300-evb.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st}/spear300.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st}/spear310-evb.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st}/spear310.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st}/spear320-evb.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st}/spear320-hmi.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st}/spear320.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st}/spear320s.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st}/spear3xx.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st}/spear600-evb.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st}/spear600.dtsi (100%)
> > 
> > 
> > All SPEAr device tree should go into stm sub-directory, as this platform is a STMicroelectronics one
> > as STi or STM32.
> 
> Just got an internal discussion, all STMicroelectronics platform should go into "st" sub-directory, and not in "stm" as indicated in my previous e-mail. ;-)
> 
> Patrice
>

Noted will do the change. If you notice other wrong categorization, feel
free to write a big list so I can fix them. In short merge stm in the st
directory. (arch_sti and arch_stm32)
Aside from that they are all correct right?

> > 
> > Thanks
> > 
> > Patrice
> > 
> >>  create mode 100644 arch/arm/boot/dts/st_ericsson/Makefile
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ab8500.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ab8505.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-db8500.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-db8520.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-db9500.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-dbx5x0-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-dbx5x0.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-ab8500.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-family-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-stuib.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-tvk1281618-r2.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-tvk1281618-r3.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href520-tvk.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefprev60-stuib.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefprev60-tvk.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefprev60.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefv60plus-stuib.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefv60plus-tvk.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefv60plus.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-nhk15.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-s8815.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-stn8815.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-snowball.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-codina.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-gavini.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-golden.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-janice.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-kyle.dts (100%)
> >>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-skomer.dts (100%)
> >>  create mode 100644 arch/arm/boot/dts/stm/Makefile
> >>  create mode 120000 arch/arm/boot/dts/stm/armv7-m.dtsi
> >>  rename arch/arm/boot/dts/{ => stm}/st-pincfg.h (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stih407-b2120.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stih407-clock.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stih407-family.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stih407-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stih407.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stih410-b2120.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stih410-b2260.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stih410-clock.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stih410-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stih410.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stih418-b2199.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stih418-b2264.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stih418-clock.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stih418.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stihxxx-b2120.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32429i-eval.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32746g-eval.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32f4-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32f429-disco.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32f429-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32f429.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32f469-disco.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32f469-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32f469.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32f7-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32f746-disco.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32f746-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32f746.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32f769-disco.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32f769-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32h7-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32h743.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32h743i-disco.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32h743i-eval.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32h750.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32h750i-art-pi.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp13-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp131.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp133.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp135.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp135f-dk.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp13xc.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp13xf.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp15-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp151.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp153.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp153c-dhcom-drc02.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-avenger96.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-dhcor-avenger96.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-dk1.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1-ctouch2-of10.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1-ctouch2.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1-edimm2.2.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-iot-box.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-microgea-stm32mp1-microdev2.0.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-microgea-stm32mp1.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-stinger96.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-stinger96.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-dhcom-pdk2.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-dhcom-picoitx.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-dk2.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-ed1.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-emsbc-argon.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-emstamp-argon.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-ev1.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-lxa-mc1.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-odyssey-som.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-odyssey.dts (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xc.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-drc02.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-pdk2.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-picoitx.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-som.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcor-avenger96.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcor-io1v8.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcor-som.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dkx.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-osd32.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxaa-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxab-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxac-pinctrl.dtsi (100%)
> >>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxad-pinctrl.dtsi (100%)

-- 
	Ansuel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Linux-stm32] [RFC PATCH 1/1] ARM/arm64: categorize dts in arm dir and fix dependency in arm64

[Patrice CHOTARD]

Hi Ansuel

On 3/28/22 13:59, Ansuel Smith wrote:
> On Mon, Mar 28, 2022 at 11:20:00AM +0200, Patrice CHOTARD wrote:
>>
>>
>> On 3/28/22 11:09, Patrice CHOTARD wrote:
>>> Hi Ansuel
>>>
>>> On 3/28/22 02:09, Ansuel Smith wrote:
>>>> - Categorize every dts in arm directory in subdirectory
>>>> - Fix Makefile to address for the arm subdirectory
>>>> - Fix any arm64 dependency
>>>>
>>>> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
>>>
>>>>  create mode 100644 arch/arm/boot/dts/st/Makefile
>>>>  rename arch/arm/boot/dts/{ => st}/spear1310-evb.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st}/spear1310.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st}/spear1340-evb.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st}/spear1340.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st}/spear13xx.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st}/spear300-evb.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st}/spear300.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st}/spear310-evb.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st}/spear310.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st}/spear320-evb.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st}/spear320-hmi.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st}/spear320.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st}/spear320s.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st}/spear3xx.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st}/spear600-evb.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st}/spear600.dtsi (100%)
>>>
>>>
>>> All SPEAr device tree should go into stm sub-directory, as this platform is a STMicroelectronics one
>>> as STi or STM32.
>>
>> Just got an internal discussion, all STMicroelectronics platform should go into "st" sub-directory, and not in "stm" as indicated in my previous e-mail. ;-)
>>
>> Patrice
>>
> 
> Noted will do the change. If you notice other wrong categorization, feel
> free to write a big list so I can fix them. In short merge stm in the st
> directory. (arch_sti and arch_stm32)
> Aside from that they are all correct right?

Yes arch_spear, arch_sti and arch_stm32 in "st" directory.
Thanks
Patrice

> 
>>>
>>> Thanks
>>>
>>> Patrice
>>>
>>>>  create mode 100644 arch/arm/boot/dts/st_ericsson/Makefile
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ab8500.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ab8505.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-db8500.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-db8520.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-db9500.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-dbx5x0-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-dbx5x0.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-ab8500.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-family-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-stuib.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-tvk1281618-r2.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href-tvk1281618-r3.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-href520-tvk.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefprev60-stuib.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefprev60-tvk.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefprev60.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefv60plus-stuib.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefv60plus-tvk.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-hrefv60plus.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-nhk15.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-s8815.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-nomadik-stn8815.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-snowball.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-codina.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-gavini.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-golden.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-janice.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-kyle.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => st_ericsson}/ste-ux500-samsung-skomer.dts (100%)
>>>>  create mode 100644 arch/arm/boot/dts/stm/Makefile
>>>>  create mode 120000 arch/arm/boot/dts/stm/armv7-m.dtsi
>>>>  rename arch/arm/boot/dts/{ => stm}/st-pincfg.h (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stih407-b2120.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stih407-clock.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stih407-family.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stih407-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stih407.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stih410-b2120.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stih410-b2260.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stih410-clock.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stih410-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stih410.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stih418-b2199.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stih418-b2264.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stih418-clock.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stih418.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stihxxx-b2120.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32429i-eval.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32746g-eval.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32f4-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32f429-disco.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32f429-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32f429.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32f469-disco.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32f469-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32f469.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32f7-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32f746-disco.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32f746-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32f746.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32f769-disco.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32f769-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32h7-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32h743.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32h743i-disco.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32h743i-eval.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32h750.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32h750i-art-pi.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp13-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp131.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp133.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp135.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp135f-dk.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp13xc.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp13xf.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp151.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp153.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp153c-dhcom-drc02.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-avenger96.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-dhcor-avenger96.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-dk1.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1-ctouch2-of10.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1-ctouch2.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1-edimm2.2.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-icore-stm32mp1.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-iot-box.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-microgea-stm32mp1-microdev2.0.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-microgea-stm32mp1.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-stinger96.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157a-stinger96.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-dhcom-pdk2.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-dhcom-picoitx.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-dk2.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-ed1.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-emsbc-argon.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-emstamp-argon.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-ev1.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-lxa-mc1.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-odyssey-som.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp157c-odyssey.dts (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xc.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-drc02.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-pdk2.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-picoitx.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcom-som.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcor-avenger96.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcor-io1v8.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dhcor-som.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-dkx.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xx-osd32.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxaa-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxab-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxac-pinctrl.dtsi (100%)
>>>>  rename arch/arm/boot/dts/{ => stm}/stm32mp15xxad-pinctrl.dtsi (100%)
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 1/1] ARM/arm64: categorize dts in arm dir and fix dependency in arm64

[Matthias Brugger]

On 28/03/2022 02:09, Ansuel Smith wrote:
> - Categorize every dts in arm directory in subdirectory
> - Fix Makefile to address for the arm subdirectory
> - Fix any arm64 dependency
> 
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> ---
[...]
>   arch/arm/boot/dts/mediatek/Makefile           |   14 +
>   .../boot/dts/{ => mediatek}/mt2701-evb.dts    |    0
>   .../boot/dts/{ => mediatek}/mt2701-pinfunc.h  |    0
>   arch/arm/boot/dts/{ => mediatek}/mt2701.dtsi  |    0
>   arch/arm/boot/dts/{ => mediatek}/mt6323.dtsi  |    0
>   .../boot/dts/{ => mediatek}/mt6580-evbp1.dts  |    0
>   arch/arm/boot/dts/{ => mediatek}/mt6580.dtsi  |    0
>   .../mt6582-prestigio-pmt5008-3g.dts           |    0
>   arch/arm/boot/dts/{ => mediatek}/mt6582.dtsi  |    0
>   .../dts/{ => mediatek}/mt6589-aquaris5.dts    |    0
>   .../{ => mediatek}/mt6589-fairphone-fp1.dts   |    0
>   arch/arm/boot/dts/{ => mediatek}/mt6589.dtsi  |    0
>   .../boot/dts/{ => mediatek}/mt6592-evb.dts    |    0
>   arch/arm/boot/dts/{ => mediatek}/mt6592.dtsi  |    0
>   arch/arm/boot/dts/{ => mediatek}/mt7623.dtsi  |    0
>   .../dts/{ => mediatek}/mt7623a-rfb-emmc.dts   |    0
>   .../dts/{ => mediatek}/mt7623a-rfb-nand.dts   |    0
>   arch/arm/boot/dts/{ => mediatek}/mt7623a.dtsi |    0
>   .../mt7623n-bananapi-bpi-r2.dts               |    0
>   .../dts/{ => mediatek}/mt7623n-rfb-emmc.dts   |    0
>   arch/arm/boot/dts/{ => mediatek}/mt7623n.dtsi |    0
>   .../boot/dts/{ => mediatek}/mt7629-rfb.dts    |    0
>   arch/arm/boot/dts/{ => mediatek}/mt7629.dtsi  |    0
>   .../boot/dts/{ => mediatek}/mt8127-moose.dts  |    0
>   arch/arm/boot/dts/{ => mediatek}/mt8127.dtsi  |    0
>   .../boot/dts/{ => mediatek}/mt8135-evbp1.dts  |    0
>   arch/arm/boot/dts/{ => mediatek}/mt8135.dtsi  |    0

Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>

Would it be possible to also script a fix for the MAINTAINERS file?

$ git grep "arch\/arm\/boot\/dts" MAINTAINERS |wc -l

101


Regards,
Matthias

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 1/1] ARM/arm64: categorize dts in arm dir and fix dependency in arm64

[Ansuel Smith]

On Mon, Mar 28, 2022 at 12:47:46PM +0200, Matthias Brugger wrote:
> 
> 
> On 28/03/2022 02:09, Ansuel Smith wrote:
> > - Categorize every dts in arm directory in subdirectory
> > - Fix Makefile to address for the arm subdirectory
> > - Fix any arm64 dependency
> > 
> > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > ---
> [...]
> >   arch/arm/boot/dts/mediatek/Makefile           |   14 +
> >   .../boot/dts/{ => mediatek}/mt2701-evb.dts    |    0
> >   .../boot/dts/{ => mediatek}/mt2701-pinfunc.h  |    0
> >   arch/arm/boot/dts/{ => mediatek}/mt2701.dtsi  |    0
> >   arch/arm/boot/dts/{ => mediatek}/mt6323.dtsi  |    0
> >   .../boot/dts/{ => mediatek}/mt6580-evbp1.dts  |    0
> >   arch/arm/boot/dts/{ => mediatek}/mt6580.dtsi  |    0
> >   .../mt6582-prestigio-pmt5008-3g.dts           |    0
> >   arch/arm/boot/dts/{ => mediatek}/mt6582.dtsi  |    0
> >   .../dts/{ => mediatek}/mt6589-aquaris5.dts    |    0
> >   .../{ => mediatek}/mt6589-fairphone-fp1.dts   |    0
> >   arch/arm/boot/dts/{ => mediatek}/mt6589.dtsi  |    0
> >   .../boot/dts/{ => mediatek}/mt6592-evb.dts    |    0
> >   arch/arm/boot/dts/{ => mediatek}/mt6592.dtsi  |    0
> >   arch/arm/boot/dts/{ => mediatek}/mt7623.dtsi  |    0
> >   .../dts/{ => mediatek}/mt7623a-rfb-emmc.dts   |    0
> >   .../dts/{ => mediatek}/mt7623a-rfb-nand.dts   |    0
> >   arch/arm/boot/dts/{ => mediatek}/mt7623a.dtsi |    0
> >   .../mt7623n-bananapi-bpi-r2.dts               |    0
> >   .../dts/{ => mediatek}/mt7623n-rfb-emmc.dts   |    0
> >   arch/arm/boot/dts/{ => mediatek}/mt7623n.dtsi |    0
> >   .../boot/dts/{ => mediatek}/mt7629-rfb.dts    |    0
> >   arch/arm/boot/dts/{ => mediatek}/mt7629.dtsi  |    0
> >   .../boot/dts/{ => mediatek}/mt8127-moose.dts  |    0
> >   arch/arm/boot/dts/{ => mediatek}/mt8127.dtsi  |    0
> >   .../boot/dts/{ => mediatek}/mt8135-evbp1.dts  |    0
> >   arch/arm/boot/dts/{ => mediatek}/mt8135.dtsi  |    0
> 
> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> 
> Would it be possible to also script a fix for the MAINTAINERS file?
> 
> $ git grep "arch\/arm\/boot\/dts" MAINTAINERS |wc -l
> 
> 101
> 
> 
> Regards,
> Matthias

Totally forgot about the MAINTAINERS file! Yes will add to the script a
check to fix also that.

-- 
	Ansuel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Jonathan Neuschäfer]

[-- Attachment #1.1: Type: text/plain, Size: 2634 bytes --]

On Mon, Mar 28, 2022 at 02:09:14AM +0200, Ansuel Smith wrote:
> Hi,
> as the title say, the intention of this ""series"" is to finally categorize
> the ARM dts directory in subdirectory for each oem.
[...]
> [1] https://gist.github.com/Ansuel/47c49925ee7ef4b1dd035afc74679ab5
> [2] https://gist.github.com/Ansuel/19f61f1e583c49407ce35c10e770fbe0

Nice idea, thank you!

A few notes on categorization below.


>  create mode 100644 arch/arm/boot/dts/broadcom/Makefile
>  rename arch/arm/boot/dts/{ => broadcom}/bcm-cygnus-clock.dtsi (100%)

Or maybe bcm instead of broadcom. Not sure which is preferred by
Broadcom people.

>  create mode 100644 arch/arm/boot/dts/dove/Makefile
>  rename arch/arm/boot/dts/{ => dove}/dove-cm-a510.dtsi (100%)

Arguably part of Marvell.

>  create mode 100644 arch/arm/boot/dts/edac/Makefile
>  rename arch/arm/boot/dts/{ => edac}/ecx-2000.dts (100%)
>  rename arch/arm/boot/dts/{ => edac}/ecx-common.dtsi (100%)
>  rename arch/arm/boot/dts/{ => edac}/highbank.dts (100%)

Why edac?
The most obvious name I can see here is calxeda.

>  create mode 100644 arch/arm/boot/dts/freescale/Makefile

Freescale has been part of NXP for a while, so it might make sense to
merge the freescale and nxp directories. I can't speak for
NXP-the-company, so that's just my view as a bystander.

>  create mode 100644 arch/arm/boot/dts/kirkwood/Makefile

The Kirkwood family should probably be sorted into Marvell.

>  create mode 100644 arch/arm/boot/dts/layerscape/Makefile
>  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-moxa-uc-8410a.dts (100%)
>  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-qds.dts (100%)
>  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-tsn.dts (100%)
>  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-twr.dts (100%)
>  rename arch/arm/boot/dts/{ => layerscape}/ls1021a.dtsi (100%)

The Layerscape family is part of Freescale/NXP.

>  create mode 120000 arch/arm/boot/dts/nxp/armv7-m.dtsi

armv7-m.dtsi is a bit confusing, because it contains a few devices at
fixed addresses, so it looks vendor-specific at a first glance into the
file. However, if it is actually as vendor-neutral as the name implies,
I think it should live dts/ directly, rather than in vendor
subdirectories.

>  rename arch/arm/boot/dts/{ => nxp}/lpc18xx.dtsi (100%)

Here we have the NXP LPCxxxx family, which is AFAIK unrelated to the
i.MX family (and thus the bulk of the Freescale legacy).

>  create mode 100644 arch/arm/boot/dts/vybrid/Makefile

Vybrid is another chip family of NXP, with a good deal of Freescale
legacy in it as evidenced by the "fsl," prefix in the devicetrees.



Thanks,
Jonathan

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Ansuel Smith]

On Mon, Mar 28, 2022 at 03:21:08PM +0200, Jonathan Neuschäfer wrote:
> On Mon, Mar 28, 2022 at 02:09:14AM +0200, Ansuel Smith wrote:
> > Hi,
> > as the title say, the intention of this ""series"" is to finally categorize
> > the ARM dts directory in subdirectory for each oem.
> [...]
> > [1] https://gist.github.com/Ansuel/47c49925ee7ef4b1dd035afc74679ab5
> > [2] https://gist.github.com/Ansuel/19f61f1e583c49407ce35c10e770fbe0
> 
> Nice idea, thank you!
> 
> A few notes on categorization below.
> 
> 
> >  create mode 100644 arch/arm/boot/dts/broadcom/Makefile
> >  rename arch/arm/boot/dts/{ => broadcom}/bcm-cygnus-clock.dtsi (100%)
> 
> Or maybe bcm instead of broadcom. Not sure which is preferred by
> Broadcom people.
> 

In arm64 they used broadcom so i assume the full name looks correct.

> >  create mode 100644 arch/arm/boot/dts/dove/Makefile
> >  rename arch/arm/boot/dts/{ => dove}/dove-cm-a510.dtsi (100%)
> 
> Arguably part of Marvell.
> 
> >  create mode 100644 arch/arm/boot/dts/edac/Makefile
> >  rename arch/arm/boot/dts/{ => edac}/ecx-2000.dts (100%)
> >  rename arch/arm/boot/dts/{ => edac}/ecx-common.dtsi (100%)
> >  rename arch/arm/boot/dts/{ => edac}/highbank.dts (100%)
> 
> Why edac?
> The most obvious name I can see here is calxeda.
> 
> >  create mode 100644 arch/arm/boot/dts/freescale/Makefile
> 
> Freescale has been part of NXP for a while, so it might make sense to
> merge the freescale and nxp directories. I can't speak for
> NXP-the-company, so that's just my view as a bystander.
> 
> >  create mode 100644 arch/arm/boot/dts/kirkwood/Makefile
> 
> The Kirkwood family should probably be sorted into Marvell.
> 
> >  create mode 100644 arch/arm/boot/dts/layerscape/Makefile
> >  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-moxa-uc-8410a.dts (100%)
> >  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-qds.dts (100%)
> >  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-tsn.dts (100%)
> >  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-twr.dts (100%)
> >  rename arch/arm/boot/dts/{ => layerscape}/ls1021a.dtsi (100%)
> 
> The Layerscape family is part of Freescale/NXP.
> 
> >  create mode 120000 arch/arm/boot/dts/nxp/armv7-m.dtsi
> 
> armv7-m.dtsi is a bit confusing, because it contains a few devices at
> fixed addresses, so it looks vendor-specific at a first glance into the
> file. However, if it is actually as vendor-neutral as the name implies,
> I think it should live dts/ directly, rather than in vendor
> subdirectories.
>

Considering it's really just 3 binding IMHO it should be just dropped
and merged in other dtsi... But lets not extend this too much.
This is really just a simplic link and armv7-m.dtsi is placed in dts/
I create links in each oem that includes it to skip any changes to the
dts.

> >  rename arch/arm/boot/dts/{ => nxp}/lpc18xx.dtsi (100%)
> 
> Here we have the NXP LPCxxxx family, which is AFAIK unrelated to the
> i.MX family (and thus the bulk of the Freescale legacy).
> 
> >  create mode 100644 arch/arm/boot/dts/vybrid/Makefile
> 
> Vybrid is another chip family of NXP, with a good deal of Freescale
> legacy in it as evidenced by the "fsl," prefix in the devicetrees.
> 
> 
> 
> Thanks,
> Jonathan

Thx for the hint hope to get more comments about the dubious
categorization about nxp and freescale.

-- 
	Ansuel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Jonathan Neuschäfer]

[-- Attachment #1.1: Type: text/plain, Size: 1776 bytes --]

On Mon, Mar 28, 2022 at 03:27:13PM +0200, Ansuel Smith wrote:
> On Mon, Mar 28, 2022 at 03:21:08PM +0200, Jonathan Neuschäfer wrote:
> > On Mon, Mar 28, 2022 at 02:09:14AM +0200, Ansuel Smith wrote:
> > > Hi,
> > > as the title say, the intention of this ""series"" is to finally categorize
> > > the ARM dts directory in subdirectory for each oem.
> > [...]
> > > [1] https://gist.github.com/Ansuel/47c49925ee7ef4b1dd035afc74679ab5
> > > [2] https://gist.github.com/Ansuel/19f61f1e583c49407ce35c10e770fbe0
> > 
> > Nice idea, thank you!
> > 
> > A few notes on categorization below.
> > 
> > 
> > >  create mode 100644 arch/arm/boot/dts/broadcom/Makefile
> > >  rename arch/arm/boot/dts/{ => broadcom}/bcm-cygnus-clock.dtsi (100%)
> > 
> > Or maybe bcm instead of broadcom. Not sure which is preferred by
> > Broadcom people.
> > 
> 
> In arm64 they used broadcom so i assume the full name looks correct.

Alright.


[...]
> > >  create mode 120000 arch/arm/boot/dts/nxp/armv7-m.dtsi
> > 
> > armv7-m.dtsi is a bit confusing, because it contains a few devices at
> > fixed addresses, so it looks vendor-specific at a first glance into the
> > file. However, if it is actually as vendor-neutral as the name implies,
> > I think it should live dts/ directly, rather than in vendor
> > subdirectories.
> >
> 
> Considering it's really just 3 binding IMHO it should be just dropped
> and merged in other dtsi... But lets not extend this too much.
> This is really just a simplic link and armv7-m.dtsi is placed in dts/
> I create links in each oem that includes it to skip any changes to the
> dts.

Ah, I missed the link bit (hidden in the file permissions) :)
I agree, this is something that can be cleaned up later.


Jonathan

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[H. Nikolaus Schaller]

> Am 28.03.2022 um 15:21 schrieb Jonathan Neuschäfer <j.neuschaefer@gmx.net>:
> 
> Or maybe bcm instead of broadcom. Not sure which is preferred by
> Broadcom people.

Maybe it should always follow the list of vendor prefixes as we are talking about DTS?

just my 2cts,
Nikolaus


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Andrew Jeffery]

On Tue, 29 Mar 2022, at 00:20, H. Nikolaus Schaller wrote:
>> Am 28.03.2022 um 15:21 schrieb Jonathan Neuschäfer <j.neuschaefer@gmx.net>:
>> 
>> Or maybe bcm instead of broadcom. Not sure which is preferred by
>> Broadcom people.
>
> Maybe it should always follow the list of vendor prefixes as we are 
> talking about DTS?

+1 (if we're actually going to do this). That would neuter most the 
mistakes and discussion and can be extracted from the dts files 
themselves.

Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: (EXT) Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Alexander Stein]

Am Montag, 28. März 2022, 15:21:08 CEST schrieb Jonathan Neuschäfer:
> * PGP Signed by an unknown key
> 
> On Mon, Mar 28, 2022 at 02:09:14AM +0200, Ansuel Smith wrote:
> > Hi,
> > as the title say, the intention of this ""series"" is to finally
> > categorize
> > the ARM dts directory in subdirectory for each oem.
> 
> [...]
> 
> > [1] https://gist.github.com/Ansuel/47c49925ee7ef4b1dd035afc74679ab5
> > [2] https://gist.github.com/Ansuel/19f61f1e583c49407ce35c10e770fbe0
> 
> Nice idea, thank you!
> 
> A few notes on categorization below.
> [...]
> >  create mode 100644 arch/arm/boot/dts/freescale/Makefile
> 
> Freescale has been part of NXP for a while, so it might make sense to
> merge the freescale and nxp directories. I can't speak for
> NXP-the-company, so that's just my view as a bystander.

Please don't mix the names for arm and arm64. It's very confusing if the 
vendor directory is named differently for each architecture.

>[...]
> >  create mode 120000 arch/arm/boot/dts/nxp/armv7-m.dtsi
> 
> armv7-m.dtsi is a bit confusing, because it contains a few devices at
> fixed addresses, so it looks vendor-specific at a first glance into the
> file. However, if it is actually as vendor-neutral as the name implies,
> I think it should live dts/ directly, rather than in vendor
> subdirectories.

This seems to be some generic devices common for all ARMv7M CPUs used in 
Cortex-M CPUs. It's also used by some stm32 .dtsi.

Best regards,
Alexander




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Alexandre Belloni]

Hi,

On 28/03/2022 15:21:08+0200, Jonathan Neuschäfer wrote:
> On Mon, Mar 28, 2022 at 02:09:14AM +0200, Ansuel Smith wrote:
> >  create mode 100644 arch/arm/boot/dts/freescale/Makefile
> 
> Freescale has been part of NXP for a while, so it might make sense to
> merge the freescale and nxp directories. I can't speak for
> NXP-the-company, so that's just my view as a bystander.
> 

Maybe we should wait for the market consolidation to end so we can put
all the files in a single subfolder?

this would save us from all the bikeshedding ;)

> >  create mode 100644 arch/arm/boot/dts/kirkwood/Makefile
> 
> The Kirkwood family should probably be sorted into Marvell.
> 
> >  create mode 100644 arch/arm/boot/dts/layerscape/Makefile
> >  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-moxa-uc-8410a.dts (100%)
> >  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-qds.dts (100%)
> >  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-tsn.dts (100%)
> >  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-twr.dts (100%)
> >  rename arch/arm/boot/dts/{ => layerscape}/ls1021a.dtsi (100%)
> 
> The Layerscape family is part of Freescale/NXP.
> 
> >  create mode 120000 arch/arm/boot/dts/nxp/armv7-m.dtsi
> 
> armv7-m.dtsi is a bit confusing, because it contains a few devices at
> fixed addresses, so it looks vendor-specific at a first glance into the
> file. However, if it is actually as vendor-neutral as the name implies,
> I think it should live dts/ directly, rather than in vendor
> subdirectories.
> 
> >  rename arch/arm/boot/dts/{ => nxp}/lpc18xx.dtsi (100%)
> 
> Here we have the NXP LPCxxxx family, which is AFAIK unrelated to the
> i.MX family (and thus the bulk of the Freescale legacy).
> 
> >  create mode 100644 arch/arm/boot/dts/vybrid/Makefile
> 
> Vybrid is another chip family of NXP, with a good deal of Freescale
> legacy in it as evidenced by the "fsl," prefix in the devicetrees.
> 
> 
> 
> Thanks,
> Jonathan



> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Krzysztof Kozlowski]

On 28/03/2022 02:09, Ansuel Smith wrote:
> Hi,
> as the title say, the intention of this ""series"" is to finally categorize
> the ARM dts directory in subdirectory for each oem.
> 
> The main reason for this is that it became unpractical to handle 2600
> dts files and try to even understand/edit/check the situation for a
> specific target.
> 
> In arm64 we already have this kind of separation and I honestly think
> that this was never proposed for ARM due to the fact that there are
> 2600+ files to sort and the fact that it will be a mess to merge this
> entirely but IMHO with a little bit of effort we can finally solve this
> problem and have a well organized directory just like arm64.
> 
> Some prerequisite on how this work was done:
> - This comes entirely from a python script created by me for the task.
>   linked here [1]
> - I had to manually categorize all the different arch in the makefile
>   based on the oem. I searched every arch on the internet trying to
>   understand the correct oem. I hope they are correct but I would love
>   some comments about them.
> - This current ""series"" is all squashed in one big commit to better
>   receive comments for this. The final version ideally would have all
>   changes in separate commits. The script can already do this, it's just
>   commented.
> 
> Here is a list of some discoveries while doing all the sorting.
> These are totally additional reason why we need this.
> 
> While creating the script I discovered some funny things:
> - We have orphan dts! There are dts that are never compiled and are
>   there just for reference. We would never have noticed this without this
>   change and probably nobody noticed it. They are currently all listed
>   in the python script.
> - We have dtsi shared across different oem. My current solution for them
>   is: NOT SORT THEM and leave them in the generic directory and create a
>   link in each oem dts that points to these dtsi. This is to try in
>   every way possible to skip any additional changes to the dts.
>   Current dtsi that suffers from this are only 3. (listed in the script)
> - arm64 dts and dtsi reference ARM dts. Obviously this change would cause
>   broken include for these special dtsi. The script creates a dependency
>   table of the entire arm64 directory and fix every broken dependency
>   (hoping they all use a sane include logic... regex is used to parse
>   all the different dependency)
> 
> So in short the script does the following steps:
> 1. Enumerate all the action to do... (dts to move, scan dependency for
>    the dts...)
> 2. Generate the arm64 dependency
> 3. Creates the Makefile
> 4. Generate the Makefiles for the current oem
> 5. Move all the related dts and dtsi for the current oem
> 6. Check broken dependency and fix them by editing the dts and writing
>    the correct include (or fix any symbolic link)
> 
> This is an output that describes all the things done by the script [2]
> 
> I really hope I didn't commit any logic mistake in the script but most
> of the work should be done.
> 

+Cc Arnd and Olof,

Ansuel,
Thanks for you patch. Please cc the SoC maintainers in such submissions.
It seems that you got some quite nice discussion, but still the core
folks are not Cced, so no one would be able to take your patch...

I am pretty sure we were discussing such split idea in the past and it
did not get traction, but I cannot recall the exact discussion.

To me the idea is good but will cause huge `git am` conflicts.
Cherry-picks, backports and merges should nicely detect path renames,
but git am (and b4 am) I think cannot.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Ansuel Smith]

On Tue, Mar 29, 2022 at 03:20:18PM +0200, Krzysztof Kozlowski wrote:
> On 28/03/2022 02:09, Ansuel Smith wrote:
> > Hi,
> > as the title say, the intention of this ""series"" is to finally categorize
> > the ARM dts directory in subdirectory for each oem.
> > 
> > The main reason for this is that it became unpractical to handle 2600
> > dts files and try to even understand/edit/check the situation for a
> > specific target.
> > 
> > In arm64 we already have this kind of separation and I honestly think
> > that this was never proposed for ARM due to the fact that there are
> > 2600+ files to sort and the fact that it will be a mess to merge this
> > entirely but IMHO with a little bit of effort we can finally solve this
> > problem and have a well organized directory just like arm64.
> > 
> > Some prerequisite on how this work was done:
> > - This comes entirely from a python script created by me for the task.
> >   linked here [1]
> > - I had to manually categorize all the different arch in the makefile
> >   based on the oem. I searched every arch on the internet trying to
> >   understand the correct oem. I hope they are correct but I would love
> >   some comments about them.
> > - This current ""series"" is all squashed in one big commit to better
> >   receive comments for this. The final version ideally would have all
> >   changes in separate commits. The script can already do this, it's just
> >   commented.
> > 
> > Here is a list of some discoveries while doing all the sorting.
> > These are totally additional reason why we need this.
> > 
> > While creating the script I discovered some funny things:
> > - We have orphan dts! There are dts that are never compiled and are
> >   there just for reference. We would never have noticed this without this
> >   change and probably nobody noticed it. They are currently all listed
> >   in the python script.
> > - We have dtsi shared across different oem. My current solution for them
> >   is: NOT SORT THEM and leave them in the generic directory and create a
> >   link in each oem dts that points to these dtsi. This is to try in
> >   every way possible to skip any additional changes to the dts.
> >   Current dtsi that suffers from this are only 3. (listed in the script)
> > - arm64 dts and dtsi reference ARM dts. Obviously this change would cause
> >   broken include for these special dtsi. The script creates a dependency
> >   table of the entire arm64 directory and fix every broken dependency
> >   (hoping they all use a sane include logic... regex is used to parse
> >   all the different dependency)
> > 
> > So in short the script does the following steps:
> > 1. Enumerate all the action to do... (dts to move, scan dependency for
> >    the dts...)
> > 2. Generate the arm64 dependency
> > 3. Creates the Makefile
> > 4. Generate the Makefiles for the current oem
> > 5. Move all the related dts and dtsi for the current oem
> > 6. Check broken dependency and fix them by editing the dts and writing
> >    the correct include (or fix any symbolic link)
> > 
> > This is an output that describes all the things done by the script [2]
> > 
> > I really hope I didn't commit any logic mistake in the script but most
> > of the work should be done.
> > 
> 
> +Cc Arnd and Olof,
> 
> Ansuel,
> Thanks for you patch. Please cc the SoC maintainers in such submissions.
> It seems that you got some quite nice discussion, but still the core
> folks are not Cced, so no one would be able to take your patch...
>

I had some problem with gmail and sending mail too much users. I put Rob
and You and all the various list to try to workaround the "gmail spam
protection"

> I am pretty sure we were discussing such split idea in the past and it
> did not get traction, but I cannot recall the exact discussion.
> 

I think the main issue here is how to handle bot and how problematic is
to merge this. As written in the cover letter the final version of this
should be a big series of 50+ patch with every commit specific to each
oem. In theory we should be able to merge the different oem separately
and try to at least start the categorization. 
Another idea I got to at least have a "migration path" is to convert
every dts in the dts/ directory to a symbolic link that target the dts
in the correct oem. But I assume that would fix only part of the problem
and git am will still be problematic.

> To me the idea is good but will cause huge `git am` conflicts.
> Cherry-picks, backports and merges should nicely detect path renames,
> but git am (and b4 am) I think cannot.
> 

I know but we should really consider this kind of change. The current
state of the dts/ directory is embarassing and keeping it that way cause
only more problems and makes this even more difficult.
Hope we find a solution and fix this for good!

> Best regards,
> Krzysztof

-- 
	Ansuel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Rob Herring]

On Tue, Mar 29, 2022 at 8:27 AM Ansuel Smith <ansuelsmth@gmail.com> wrote:
>
> On Tue, Mar 29, 2022 at 03:20:18PM +0200, Krzysztof Kozlowski wrote:
> > On 28/03/2022 02:09, Ansuel Smith wrote:
> > > Hi,
> > > as the title say, the intention of this ""series"" is to finally categorize
> > > the ARM dts directory in subdirectory for each oem.
> > >
> > > The main reason for this is that it became unpractical to handle 2600
> > > dts files and try to even understand/edit/check the situation for a
> > > specific target.
> > >
> > > In arm64 we already have this kind of separation and I honestly think
> > > that this was never proposed for ARM due to the fact that there are
> > > 2600+ files to sort and the fact that it will be a mess to merge this
> > > entirely but IMHO with a little bit of effort we can finally solve this
> > > problem and have a well organized directory just like arm64.
> > >
> > > Some prerequisite on how this work was done:
> > > - This comes entirely from a python script created by me for the task.
> > >   linked here [1]
> > > - I had to manually categorize all the different arch in the makefile
> > >   based on the oem. I searched every arch on the internet trying to
> > >   understand the correct oem. I hope they are correct but I would love
> > >   some comments about them.
> > > - This current ""series"" is all squashed in one big commit to better
> > >   receive comments for this. The final version ideally would have all
> > >   changes in separate commits. The script can already do this, it's just
> > >   commented.
> > >
> > > Here is a list of some discoveries while doing all the sorting.
> > > These are totally additional reason why we need this.
> > >
> > > While creating the script I discovered some funny things:
> > > - We have orphan dts! There are dts that are never compiled and are
> > >   there just for reference. We would never have noticed this without this
> > >   change and probably nobody noticed it. They are currently all listed
> > >   in the python script.
> > > - We have dtsi shared across different oem. My current solution for them
> > >   is: NOT SORT THEM and leave them in the generic directory and create a
> > >   link in each oem dts that points to these dtsi. This is to try in
> > >   every way possible to skip any additional changes to the dts.
> > >   Current dtsi that suffers from this are only 3. (listed in the script)
> > > - arm64 dts and dtsi reference ARM dts. Obviously this change would cause
> > >   broken include for these special dtsi. The script creates a dependency
> > >   table of the entire arm64 directory and fix every broken dependency
> > >   (hoping they all use a sane include logic... regex is used to parse
> > >   all the different dependency)
> > >
> > > So in short the script does the following steps:
> > > 1. Enumerate all the action to do... (dts to move, scan dependency for
> > >    the dts...)
> > > 2. Generate the arm64 dependency
> > > 3. Creates the Makefile
> > > 4. Generate the Makefiles for the current oem
> > > 5. Move all the related dts and dtsi for the current oem
> > > 6. Check broken dependency and fix them by editing the dts and writing
> > >    the correct include (or fix any symbolic link)
> > >
> > > This is an output that describes all the things done by the script [2]
> > >
> > > I really hope I didn't commit any logic mistake in the script but most
> > > of the work should be done.
> > >
> >
> > +Cc Arnd and Olof,
> >
> > Ansuel,
> > Thanks for you patch. Please cc the SoC maintainers in such submissions.
> > It seems that you got some quite nice discussion, but still the core
> > folks are not Cced, so no one would be able to take your patch...
> >
>
> I had some problem with gmail and sending mail too much users. I put Rob
> and You and all the various list to try to workaround the "gmail spam
> protection"
>
> > I am pretty sure we were discussing such split idea in the past and it
> > did not get traction, but I cannot recall the exact discussion.
> >
>
> I think the main issue here is how to handle bot and how problematic is
> to merge this. As written in the cover letter the final version of this
> should be a big series of 50+ patch with every commit specific to each
> oem. In theory we should be able to merge the different oem separately
> and try to at least start the categorization.
> Another idea I got to at least have a "migration path" is to convert
> every dts in the dts/ directory to a symbolic link that target the dts
> in the correct oem. But I assume that would fix only part of the problem
> and git am will still be problematic.

I have a script[1] that does the conversion written the last time this
came up. Just have to agree on directory names. I think the easiest
would be for Arnd/Olof to run it at the end of a merge window before
rc1.

I'm very much in favor of this happening especially before *any*
overlays are added to add to the mess (it's probably already
happened).

Rob

[1] https://lore.kernel.org/all/20181204183649.GA5716@bogus/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Ansuel Smith]

Il giorno mar 25 apr 2023 alle ore 00:10 Rob Herring
<robh+dt@kernel.org> ha scritto:
>
> On Tue, Mar 29, 2022 at 8:27 AM Ansuel Smith <ansuelsmth@gmail.com> wrote:
> >
> > On Tue, Mar 29, 2022 at 03:20:18PM +0200, Krzysztof Kozlowski wrote:
> > > On 28/03/2022 02:09, Ansuel Smith wrote:
> > > > Hi,
> > > > as the title say, the intention of this ""series"" is to finally categorize
> > > > the ARM dts directory in subdirectory for each oem.
> > > >
> > > > The main reason for this is that it became unpractical to handle 2600
> > > > dts files and try to even understand/edit/check the situation for a
> > > > specific target.
> > > >
> > > > In arm64 we already have this kind of separation and I honestly think
> > > > that this was never proposed for ARM due to the fact that there are
> > > > 2600+ files to sort and the fact that it will be a mess to merge this
> > > > entirely but IMHO with a little bit of effort we can finally solve this
> > > > problem and have a well organized directory just like arm64.
> > > >
> > > > Some prerequisite on how this work was done:
> > > > - This comes entirely from a python script created by me for the task.
> > > >   linked here [1]
> > > > - I had to manually categorize all the different arch in the makefile
> > > >   based on the oem. I searched every arch on the internet trying to
> > > >   understand the correct oem. I hope they are correct but I would love
> > > >   some comments about them.
> > > > - This current ""series"" is all squashed in one big commit to better
> > > >   receive comments for this. The final version ideally would have all
> > > >   changes in separate commits. The script can already do this, it's just
> > > >   commented.
> > > >
> > > > Here is a list of some discoveries while doing all the sorting.
> > > > These are totally additional reason why we need this.
> > > >
> > > > While creating the script I discovered some funny things:
> > > > - We have orphan dts! There are dts that are never compiled and are
> > > >   there just for reference. We would never have noticed this without this
> > > >   change and probably nobody noticed it. They are currently all listed
> > > >   in the python script.
> > > > - We have dtsi shared across different oem. My current solution for them
> > > >   is: NOT SORT THEM and leave them in the generic directory and create a
> > > >   link in each oem dts that points to these dtsi. This is to try in
> > > >   every way possible to skip any additional changes to the dts.
> > > >   Current dtsi that suffers from this are only 3. (listed in the script)
> > > > - arm64 dts and dtsi reference ARM dts. Obviously this change would cause
> > > >   broken include for these special dtsi. The script creates a dependency
> > > >   table of the entire arm64 directory and fix every broken dependency
> > > >   (hoping they all use a sane include logic... regex is used to parse
> > > >   all the different dependency)
> > > >
> > > > So in short the script does the following steps:
> > > > 1. Enumerate all the action to do... (dts to move, scan dependency for
> > > >    the dts...)
> > > > 2. Generate the arm64 dependency
> > > > 3. Creates the Makefile
> > > > 4. Generate the Makefiles for the current oem
> > > > 5. Move all the related dts and dtsi for the current oem
> > > > 6. Check broken dependency and fix them by editing the dts and writing
> > > >    the correct include (or fix any symbolic link)
> > > >
> > > > This is an output that describes all the things done by the script [2]
> > > >
> > > > I really hope I didn't commit any logic mistake in the script but most
> > > > of the work should be done.
> > > >
> > >
> > > +Cc Arnd and Olof,
> > >
> > > Ansuel,
> > > Thanks for you patch. Please cc the SoC maintainers in such submissions.
> > > It seems that you got some quite nice discussion, but still the core
> > > folks are not Cced, so no one would be able to take your patch...
> > >
> >
> > I had some problem with gmail and sending mail too much users. I put Rob
> > and You and all the various list to try to workaround the "gmail spam
> > protection"
> >
> > > I am pretty sure we were discussing such split idea in the past and it
> > > did not get traction, but I cannot recall the exact discussion.
> > >
> >
> > I think the main issue here is how to handle bot and how problematic is
> > to merge this. As written in the cover letter the final version of this
> > should be a big series of 50+ patch with every commit specific to each
> > oem. In theory we should be able to merge the different oem separately
> > and try to at least start the categorization.
> > Another idea I got to at least have a "migration path" is to convert
> > every dts in the dts/ directory to a symbolic link that target the dts
> > in the correct oem. But I assume that would fix only part of the problem
> > and git am will still be problematic.
>
> I have a script[1] that does the conversion written the last time this
> came up. Just have to agree on directory names. I think the easiest
> would be for Arnd/Olof to run it at the end of a merge window before
> rc1.
>
> I'm very much in favor of this happening especially before *any*
> overlays are added to add to the mess (it's probably already
> happened).
>
> Rob
>
> [1] https://lore.kernel.org/all/20181204183649.GA5716@bogus/

Hi Rob,
thanks for recovering this. I remember also providing a script.

Anyway considering the amount of stuff to move, I feel like some
OEM might be problematic to move due to rebase and merging problems.

We should consider accepting moving only some and keep other
in the unsorted path. And move them at the first time possible with
the help of the maintainers.

One main blocker of this is some qcom dts that are linked to arm64
directory, so for some dts special care is needed.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Matthias Brugger]

On 25/04/2023 00:23, Ansuel Smith wrote:
> Il giorno mar 25 apr 2023 alle ore 00:10 Rob Herring
> <robh+dt@kernel.org> ha scritto:
>>
>> On Tue, Mar 29, 2022 at 8:27 AM Ansuel Smith <ansuelsmth@gmail.com> wrote:
>>>
>>> On Tue, Mar 29, 2022 at 03:20:18PM +0200, Krzysztof Kozlowski wrote:
>>>> On 28/03/2022 02:09, Ansuel Smith wrote:
>>>>> Hi,
>>>>> as the title say, the intention of this ""series"" is to finally categorize
>>>>> the ARM dts directory in subdirectory for each oem.
>>>>>
>>>>> The main reason for this is that it became unpractical to handle 2600
>>>>> dts files and try to even understand/edit/check the situation for a
>>>>> specific target.
>>>>>
>>>>> In arm64 we already have this kind of separation and I honestly think
>>>>> that this was never proposed for ARM due to the fact that there are
>>>>> 2600+ files to sort and the fact that it will be a mess to merge this
>>>>> entirely but IMHO with a little bit of effort we can finally solve this
>>>>> problem and have a well organized directory just like arm64.
>>>>>
>>>>> Some prerequisite on how this work was done:
>>>>> - This comes entirely from a python script created by me for the task.
>>>>>    linked here [1]
>>>>> - I had to manually categorize all the different arch in the makefile
>>>>>    based on the oem. I searched every arch on the internet trying to
>>>>>    understand the correct oem. I hope they are correct but I would love
>>>>>    some comments about them.
>>>>> - This current ""series"" is all squashed in one big commit to better
>>>>>    receive comments for this. The final version ideally would have all
>>>>>    changes in separate commits. The script can already do this, it's just
>>>>>    commented.
>>>>>
>>>>> Here is a list of some discoveries while doing all the sorting.
>>>>> These are totally additional reason why we need this.
>>>>>
>>>>> While creating the script I discovered some funny things:
>>>>> - We have orphan dts! There are dts that are never compiled and are
>>>>>    there just for reference. We would never have noticed this without this
>>>>>    change and probably nobody noticed it. They are currently all listed
>>>>>    in the python script.
>>>>> - We have dtsi shared across different oem. My current solution for them
>>>>>    is: NOT SORT THEM and leave them in the generic directory and create a
>>>>>    link in each oem dts that points to these dtsi. This is to try in
>>>>>    every way possible to skip any additional changes to the dts.
>>>>>    Current dtsi that suffers from this are only 3. (listed in the script)
>>>>> - arm64 dts and dtsi reference ARM dts. Obviously this change would cause
>>>>>    broken include for these special dtsi. The script creates a dependency
>>>>>    table of the entire arm64 directory and fix every broken dependency
>>>>>    (hoping they all use a sane include logic... regex is used to parse
>>>>>    all the different dependency)
>>>>>
>>>>> So in short the script does the following steps:
>>>>> 1. Enumerate all the action to do... (dts to move, scan dependency for
>>>>>     the dts...)
>>>>> 2. Generate the arm64 dependency
>>>>> 3. Creates the Makefile
>>>>> 4. Generate the Makefiles for the current oem
>>>>> 5. Move all the related dts and dtsi for the current oem
>>>>> 6. Check broken dependency and fix them by editing the dts and writing
>>>>>     the correct include (or fix any symbolic link)
>>>>>
>>>>> This is an output that describes all the things done by the script [2]
>>>>>
>>>>> I really hope I didn't commit any logic mistake in the script but most
>>>>> of the work should be done.
>>>>>
>>>>
>>>> +Cc Arnd and Olof,
>>>>
>>>> Ansuel,
>>>> Thanks for you patch. Please cc the SoC maintainers in such submissions.
>>>> It seems that you got some quite nice discussion, but still the core
>>>> folks are not Cced, so no one would be able to take your patch...
>>>>
>>>
>>> I had some problem with gmail and sending mail too much users. I put Rob
>>> and You and all the various list to try to workaround the "gmail spam
>>> protection"
>>>
>>>> I am pretty sure we were discussing such split idea in the past and it
>>>> did not get traction, but I cannot recall the exact discussion.
>>>>
>>>
>>> I think the main issue here is how to handle bot and how problematic is
>>> to merge this. As written in the cover letter the final version of this
>>> should be a big series of 50+ patch with every commit specific to each
>>> oem. In theory we should be able to merge the different oem separately
>>> and try to at least start the categorization.
>>> Another idea I got to at least have a "migration path" is to convert
>>> every dts in the dts/ directory to a symbolic link that target the dts
>>> in the correct oem. But I assume that would fix only part of the problem
>>> and git am will still be problematic.
>>
>> I have a script[1] that does the conversion written the last time this
>> came up. Just have to agree on directory names. I think the easiest
>> would be for Arnd/Olof to run it at the end of a merge window before
>> rc1.
>>
>> I'm very much in favor of this happening especially before *any*
>> overlays are added to add to the mess (it's probably already
>> happened).
>>
>> Rob
>>
>> [1] https://lore.kernel.org/all/20181204183649.GA5716@bogus/
> 
> Hi Rob,
> thanks for recovering this. I remember also providing a script.
> 
> Anyway considering the amount of stuff to move, I feel like some
> OEM might be problematic to move due to rebase and merging problems.
> 
> We should consider accepting moving only some and keep other
> in the unsorted path. And move them at the first time possible with
> the help of the maintainers.
> 
> One main blocker of this is some qcom dts that are linked to arm64
> directory, so for some dts special care is needed.
> 

Same happens for broadcom RaspberryPi DTS. The arm64 ones include the arm ones.

Regards,
Matthias

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Geert Uytterhoeven]

Hi Rob,

On Tue, Apr 25, 2023 at 12:16 AM Rob Herring <robh+dt@kernel.org> wrote:
> I have a script[1] that does the conversion written the last time this
> came up. Just have to agree on directory names. I think the easiest
> would be for Arnd/Olof to run it at the end of a merge window before
> rc1.

"emev2" and "sh7" are missing for renesas.

Does your script also cater for .dts files not matching any pattern,
but including a .dtsi file that does match a pattern?

> I'm very much in favor of this happening especially before *any*
> overlays are added to add to the mess (it's probably already
> happened).

;-)

> [1] https://lore.kernel.org/all/20181204183649.GA5716@bogus/

Thanks!

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Rob Herring]

On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Rob,
>
> On Tue, Apr 25, 2023 at 12:16 AM Rob Herring <robh+dt@kernel.org> wrote:
> > I have a script[1] that does the conversion written the last time this
> > came up. Just have to agree on directory names. I think the easiest
> > would be for Arnd/Olof to run it at the end of a merge window before
> > rc1.
>
> "emev2" and "sh7" are missing for renesas.

No doubt it's been bitrotting (or I may have missed some).

> Does your script also cater for .dts files not matching any pattern,
> but including a .dtsi file that does match a pattern?

I assume I built everything after moving, but maybe not...

That's all just "details". First, we need agreement on a) moving
things to subdirs and b) doing it 1-by-1 or all at once. So far we've
been stuck on a) for being 'too much churn'.

One nice thing with subdirs is 'make CHECK_DTBS=y
arch/arm/boot/dts/foo/' can build everything for a platform family
without having to mess with the kconfig. Maybe most folks don't care,
but I do. My CI job running schema checks looks like this to deal with
grouping the arm dts files (this list is probably out of date too, but
less so):

        if [ "$ARCH" = "arm" ]; then
            VENDOR_LIST="alphascale alpine artpec aspeed axm bcm cx9
(ecx|highbank) \
              efm ep7 imx1 imx23 imx28 imx27 imx5 imx6 imx7 ls vf qcom \
              (am3|am4|am5|dra|keystone|omap|compulab|logicpd|elpida|motorola-cpcap|da|dm)
\
              nspire armada dove kirkwood orion mvebu mmp2 berlin pxa
(arm-|integ|mps|ve) \
              (at91|sama|usb_|tny_|mpa1600|animeo_ip|aks-cdu|ethernut5|evk-pro3|pm9g45|ge86)
\
              exynos s3c s5p gemini (hisi|hi3|hip) mt meson moxa nuvo
lpc owl ox8 \
              (r7|r8|r9|emev2|sh73a|gr-|iwg) (rk|rv11) socfpga stm
(sti|st-pin) ste \
              spear (sun|axp) tegra uniph (vt8500|wm8) xen zynq"
        else
            VENDOR_LIST=$(ls arch/$ARCH/boot/dts/ | xargs)
        fi

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Matthias Brugger]

On 25/04/2023 17:57, Rob Herring wrote:
> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>
>> Hi Rob,
>>
>> On Tue, Apr 25, 2023 at 12:16 AM Rob Herring <robh+dt@kernel.org> wrote:
>>> I have a script[1] that does the conversion written the last time this
>>> came up. Just have to agree on directory names. I think the easiest
>>> would be for Arnd/Olof to run it at the end of a merge window before
>>> rc1.
>>
>> "emev2" and "sh7" are missing for renesas.
> 
> No doubt it's been bitrotting (or I may have missed some).
> 
>> Does your script also cater for .dts files not matching any pattern,
>> but including a .dtsi file that does match a pattern?
> 
> I assume I built everything after moving, but maybe not...
> 
> That's all just "details". First, we need agreement on a) moving
> things to subdirs and b) doing it 1-by-1 or all at once. So far we've
> been stuck on a) for being 'too much churn'.
> 

I think it makes sense to move them and probably the best way to do so is, as 
you proposed: that Arnd or Olof run the script to move them just before -rc1

Regards,
Matthias

> One nice thing with subdirs is 'make CHECK_DTBS=y
> arch/arm/boot/dts/foo/' can build everything for a platform family
> without having to mess with the kconfig. Maybe most folks don't care,
> but I do. My CI job running schema checks looks like this to deal with
> grouping the arm dts files (this list is probably out of date too, but
> less so):
> 
>          if [ "$ARCH" = "arm" ]; then
>              VENDOR_LIST="alphascale alpine artpec aspeed axm bcm cx9
> (ecx|highbank) \
>                efm ep7 imx1 imx23 imx28 imx27 imx5 imx6 imx7 ls vf qcom \
>                (am3|am4|am5|dra|keystone|omap|compulab|logicpd|elpida|motorola-cpcap|da|dm)
> \
>                nspire armada dove kirkwood orion mvebu mmp2 berlin pxa
> (arm-|integ|mps|ve) \
>                (at91|sama|usb_|tny_|mpa1600|animeo_ip|aks-cdu|ethernut5|evk-pro3|pm9g45|ge86)
> \
>                exynos s3c s5p gemini (hisi|hi3|hip) mt meson moxa nuvo
> lpc owl ox8 \
>                (r7|r8|r9|emev2|sh73a|gr-|iwg) (rk|rv11) socfpga stm
> (sti|st-pin) ste \
>                spear (sun|axp) tegra uniph (vt8500|wm8) xen zynq"
>          else
>              VENDOR_LIST=$(ls arch/$ARCH/boot/dts/ | xargs)
>          fi
> 
> Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Geert Uytterhoeven]

On Thu, Apr 27, 2023 at 9:37 AM Matthias Brugger <matthias.bgg@gmail.com> wrote:
> On 25/04/2023 17:57, Rob Herring wrote:
> > On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >> On Tue, Apr 25, 2023 at 12:16 AM Rob Herring <robh+dt@kernel.org> wrote:
> >>> I have a script[1] that does the conversion written the last time this
> >>> came up. Just have to agree on directory names. I think the easiest
> >>> would be for Arnd/Olof to run it at the end of a merge window before
> >>> rc1.
> >>
> >> "emev2" and "sh7" are missing for renesas.
> >
> > No doubt it's been bitrotting (or I may have missed some).
> >
> >> Does your script also cater for .dts files not matching any pattern,
> >> but including a .dtsi file that does match a pattern?
> >
> > I assume I built everything after moving, but maybe not...
> >
> > That's all just "details". First, we need agreement on a) moving
> > things to subdirs and b) doing it 1-by-1 or all at once. So far we've
> > been stuck on a) for being 'too much churn'.
> >
>
> I think it makes sense to move them and probably the best way to do so is, as
> you proposed: that Arnd or Olof run the script to move them just before -rc1

FTR, no objections from my side.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Tony Lindgren]

* Geert Uytterhoeven <geert@linux-m68k.org> [230427 07:47]:
> On Thu, Apr 27, 2023 at 9:37 AM Matthias Brugger <matthias.bgg@gmail.com> wrote:
> > On 25/04/2023 17:57, Rob Herring wrote:
> > > On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > >> On Tue, Apr 25, 2023 at 12:16 AM Rob Herring <robh+dt@kernel.org> wrote:
> > >>> I have a script[1] that does the conversion written the last time this
> > >>> came up. Just have to agree on directory names. I think the easiest
> > >>> would be for Arnd/Olof to run it at the end of a merge window before
> > >>> rc1.
> > >>
> > >> "emev2" and "sh7" are missing for renesas.
> > >
> > > No doubt it's been bitrotting (or I may have missed some).
> > >
> > >> Does your script also cater for .dts files not matching any pattern,
> > >> but including a .dtsi file that does match a pattern?
> > >
> > > I assume I built everything after moving, but maybe not...
> > >
> > > That's all just "details". First, we need agreement on a) moving
> > > things to subdirs and b) doing it 1-by-1 or all at once. So far we've
> > > been stuck on a) for being 'too much churn'.
> > >
> >
> > I think it makes sense to move them and probably the best way to do so is, as
> > you proposed: that Arnd or Olof run the script to move them just before -rc1
> 
> FTR, no objections from my side.

Sounds good to me.

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Arnd Bergmann]

On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
>> Does your script also cater for .dts files not matching any pattern,
>> but including a .dtsi file that does match a pattern?
>
> I assume I built everything after moving, but maybe not...
>
> That's all just "details". First, we need agreement on a) moving
> things to subdirs and b) doing it 1-by-1 or all at once. So far we've
> been stuck on a) for being 'too much churn'.

Sorry for missing most of the discussion last week. The script sounds
fine to me, the only reason I didn't want to do this in the past is that
we had the plan to move platforms out of the kernel tree to an external
repository and I wanted to do this platform at a time and also only move
each one once. I don't think that is going to happen anytime soon now,
so let's just do your script.

Can you send me the script and/or a pull request of the resulting
tree based on my soc/dt branch? Everything is merged upstream,
and I think git-merge would handle the remaining merges with any
other changes in mainline.

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Rob Herring]

On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
> > On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> >> Does your script also cater for .dts files not matching any pattern,
> >> but including a .dtsi file that does match a pattern?
> >
> > I assume I built everything after moving, but maybe not...
> >
> > That's all just "details". First, we need agreement on a) moving
> > things to subdirs and b) doing it 1-by-1 or all at once. So far we've
> > been stuck on a) for being 'too much churn'.
>
> Sorry for missing most of the discussion last week. The script sounds
> fine to me, the only reason I didn't want to do this in the past is that
> we had the plan to move platforms out of the kernel tree to an external
> repository and I wanted to do this platform at a time and also only move
> each one once. I don't think that is going to happen anytime soon now,
> so let's just do your script.
>
> Can you send me the script and/or a pull request of the resulting
> tree based on my soc/dt branch? Everything is merged upstream,
> and I think git-merge would handle the remaining merges with any
> other changes in mainline.

I've dusted off my script and made a branch[1] with the result.
There's just a couple of fixes needed after the script is run (see the
top commit). The cross arch includes are all fixed up by the script.
dtbs_install maintains a flat install. I compared the number of .dtbs
before and after to check the script.

I think the only issue remaining is finalizing the mapping of
platforms to subdirs. What I have currently is a mixture of SoC
families and vendors. The most notable are all the Freescale/NXP
platforms, pxa, socfpga, and stm32. It's not consistent with arm64
either. Once that's finalized, I still need to go update MAINTAINERS.

Here's the current mapping:

vendor_map = {
    'alphascale' : 'alphascale',
    'alpine' : 'alpine',
    'artpec' : 'axis',
    'axm' : 'lsi',
    'cx9' : 'cnxt',
    'ecx' : 'calxeda',
    'highbank' : 'calxeda',
    'ep7' : 'cirrus',
    'mxs': 'mxs',
    'imx23': 'mxs',
    'imx28': 'mxs',
    'sun' : 'allwinner',
    'imx': 'imx',
    'e6' : 'imx',
    'e7' : 'imx',
    'mba6' : 'imx',
    'ls': 'fsl',
    'vf': 'fsl',
    'qcom': 'qcom',
    'am3' : 'ti',
    'am4' : 'ti',
    'am5' : 'ti',
    'dra' : 'ti',
    'keystone' : 'ti',
    'omap' : 'ti',
    'compulab' : 'ti',
    'logicpd' : 'ti',
    'elpida' : 'ti',
    'motorola' : 'ti',
    'twl' : 'ti',
    'da' : 'ti',
    'dm' : 'ti',
    'nspire' : 'nspire',
    'armada' : 'marvell',
    'dove' : 'marvell',
    'kirkwood' : 'marvell',
    'orion' : 'marvell',
    'mvebu' : 'marvell',
    'mmp' : 'marvell',
    'berlin' : 'berlin',
    'pxa2' : 'pxa',
    'pxa3' : 'pxa',
    'pxa' : 'marvell',
    'arm-' : 'arm',
    'integ' : 'arm',
    'mps' : 'arm',
    've' : 'arm',
    'aspeed' : 'aspeed',
    'ast2' : 'aspeed',
    'facebook' : 'aspeed',
    'ibm' : 'aspeed',
    'openbmc' : 'aspeed',
    'en7' : 'airoha',
    'at91' : 'microchip',
    'sama' : 'microchip',
    'sam9' : 'microchip',
    'usb_' : 'microchip',
    'tny_' : 'microchip',
    'mpa1600' : 'microchip',
    'animeo_ip' : 'microchip',
    'aks-cdu' : 'microchip',
    'ethernut5' : 'microchip',
    'evk-pro3' : 'microchip',
    'pm9g45' : 'microchip',
    'ge86' : 'microchip',
    'bcm' : 'brcm',
    'exynos' : 'samsung',
    's3c' : 'samsung',
    's5p' : 'samsung',
    'gemini' : 'gemini',
    'hi3' : 'hisilicon',
    'hip' : 'hisilicon',
    'hisi' : 'hisilicon',
    'sd5' : 'hisilicon',
    'hpe' : 'hpe',
    'intel': 'intel',
    'mt' : 'mediatek',
    'meson' : 'meson',
    'moxa' : 'moxa',
    'mstar' : 'mstar',
    'nuvo' : 'nuvoton',
    'lpc' : 'lpc',
    'lan96' : 'microchip',
    'owl' : 'actions',
    'ox8' : 'oxsemi',
    'rda' : 'rda',
    'rtd' : 'realtek',
    'r7' : 'renesas',
    'r8' : 'renesas',
    'r9' : 'renesas',
    'emev2' : 'renesas',
    'sh73a' : 'renesas',
    'gr-' : 'renesas',
    'iwg' : 'renesas',
    'rk' : 'rockchip',
    'rv11' : 'rockchip',
    'rockchip' : 'rockchip',
    'socfpga' : 'socfpga',
    'stm' : 'stm32',
    'sti' : 'sti',
    'st-pin' : 'sti',
    'ste' : 'st-ericsson',
    'spear' : 'spear',
    'axp' : 'allwinner',
    'tegra' : 'nvidia',
    'milbeaut' : 'socionext',
    'uniph' : 'socionext',
    'vt8500' : 'vt8500',
    'wm8' : 'vt8500',
    'xen' : 'xen',
    'zx' : 'zte',
    'zynq' : 'xilinx',
}

Rob

[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git arm-dts-move-v2

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Krzysztof Kozlowski]

On 02/05/2023 21:40, Rob Herring wrote:
> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
>>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>
>>>> Does your script also cater for .dts files not matching any pattern,
>>>> but including a .dtsi file that does match a pattern?
>>>
>>> I assume I built everything after moving, but maybe not...
>>>
>>> That's all just "details". First, we need agreement on a) moving
>>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've
>>> been stuck on a) for being 'too much churn'.
>>
>> Sorry for missing most of the discussion last week. The script sounds
>> fine to me, the only reason I didn't want to do this in the past is that
>> we had the plan to move platforms out of the kernel tree to an external
>> repository and I wanted to do this platform at a time and also only move
>> each one once. I don't think that is going to happen anytime soon now,
>> so let's just do your script.
>>
>> Can you send me the script and/or a pull request of the resulting
>> tree based on my soc/dt branch? Everything is merged upstream,
>> and I think git-merge would handle the remaining merges with any
>> other changes in mainline.
> 
> I've dusted off my script and made a branch[1] with the result.
> There's just a couple of fixes needed after the script is run (see the
> top commit). The cross arch includes are all fixed up by the script.
> dtbs_install maintains a flat install. I compared the number of .dtbs
> before and after to check the script.
> 
> I think the only issue remaining is finalizing the mapping of
> platforms to subdirs. What I have currently is a mixture of SoC
> families and vendors. The most notable are all the Freescale/NXP
> platforms, pxa, socfpga, and stm32. It's not consistent with arm64
> either. Once that's finalized, I still need to go update MAINTAINERS.
> 
> Here's the current mapping:
> 
> vendor_map = {
>     'alphascale' : 'alphascale',
>     'alpine' : 'alpine',
>     'artpec' : 'axis',
>     'axm' : 'lsi',
>     'cx9' : 'cnxt',
>     'ecx' : 'calxeda',
>     'highbank' : 'calxeda',
>     'ep7' : 'cirrus',
>     'mxs': 'mxs',
>     'imx23': 'mxs',
>     'imx28': 'mxs',
>     'sun' : 'allwinner',
>     'imx': 'imx',
>     'e6' : 'imx',
>     'e7' : 'imx',
>     'mba6' : 'imx',
>     'ls': 'fsl',
>     'vf': 'fsl',

If I remember correctly, Vybrid are a bit closer to iMX than to LS
(Layerscape), but it should be Shawn's call (+Cc).

>     'qcom': 'qcom',
>     'am3' : 'ti',
>     'am4' : 'ti',
>     'am5' : 'ti',
>     'dra' : 'ti',
>     'keystone' : 'ti',
>     'omap' : 'ti',
>     'compulab' : 'ti',
>     'logicpd' : 'ti',
>     'elpida' : 'ti',
>     'motorola' : 'ti',
>     'twl' : 'ti',
>     'da' : 'ti',
>     'dm' : 'ti',
>     'nspire' : 'nspire',
>     'armada' : 'marvell',
>     'dove' : 'marvell',
>     'kirkwood' : 'marvell',
>     'orion' : 'marvell',
>     'mvebu' : 'marvell',
>     'mmp' : 'marvell',
>     'berlin' : 'berlin',
>     'pxa2' : 'pxa',
>     'pxa3' : 'pxa',
>     'pxa' : 'marvell',
>     'arm-' : 'arm',
>     'integ' : 'arm',
>     'mps' : 'arm',
>     've' : 'arm',
>     'aspeed' : 'aspeed',
>     'ast2' : 'aspeed',
>     'facebook' : 'aspeed',
>     'ibm' : 'aspeed',
>     'openbmc' : 'aspeed',
>     'en7' : 'airoha',
>     'at91' : 'microchip',
>     'sama' : 'microchip',
>     'sam9' : 'microchip',
>     'usb_' : 'microchip',
>     'tny_' : 'microchip',
>     'mpa1600' : 'microchip',
>     'animeo_ip' : 'microchip',
>     'aks-cdu' : 'microchip',
>     'ethernut5' : 'microchip',
>     'evk-pro3' : 'microchip',
>     'pm9g45' : 'microchip',
>     'ge86' : 'microchip',
>     'bcm' : 'brcm',
>     'exynos' : 'samsung',
>     's3c' : 'samsung',
>     's5p' : 'samsung',

For samsung looks good.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

>     'gemini' : 'gemini',
>     'hi3' : 'hisilicon',
>     'hip' : 'hisilicon',
>     'hisi' : 'hisilicon',
>     'sd5' : 'hisilicon',
>     'hpe' : 'hpe',
>     'intel': 'intel',
>     'mt' : 'mediatek',
>     'meson' : 'meson',
>     'moxa' : 'moxa',
>     'mstar' : 'mstar',
>     'nuvo' : 'nuvoton',
>     'lpc' : 'lpc',
>     'lan96' : 'microchip',
>     'owl' : 'actions',
>     'ox8' : 'oxsemi',
>     'rda' : 'rda',
>     'rtd' : 'realtek',
>     'r7' : 'renesas',
>     'r8' : 'renesas',
>     'r9' : 'renesas',
>     'emev2' : 'renesas',
>     'sh73a' : 'renesas',
>     'gr-' : 'renesas',
>     'iwg' : 'renesas',
>     'rk' : 'rockchip',
>     'rv11' : 'rockchip',
>     'rockchip' : 'rockchip',
>     'socfpga' : 'socfpga',
>     'stm' : 'stm32',
>     'sti' : 'sti',
>     'st-pin' : 'sti',
>     'ste' : 'st-ericsson',
>     'spear' : 'spear',
>     'axp' : 'allwinner',
>     'tegra' : 'nvidia',
>     'milbeaut' : 'socionext',
>     'uniph' : 'socionext',
>     'vt8500' : 'vt8500',
>     'wm8' : 'vt8500',
>     'xen' : 'xen',
>     'zx' : 'zte',
>     'zynq' : 'xilinx',

The rest looks good to me, but I don't know half of these :)

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Shawn Guo]

On Tue, May 02, 2023 at 10:02:03PM +0200, Krzysztof Kozlowski wrote:
> On 02/05/2023 21:40, Rob Herring wrote:
> > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
> >>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >>>
> >>>> Does your script also cater for .dts files not matching any pattern,
> >>>> but including a .dtsi file that does match a pattern?
> >>>
> >>> I assume I built everything after moving, but maybe not...
> >>>
> >>> That's all just "details". First, we need agreement on a) moving
> >>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've
> >>> been stuck on a) for being 'too much churn'.
> >>
> >> Sorry for missing most of the discussion last week. The script sounds
> >> fine to me, the only reason I didn't want to do this in the past is that
> >> we had the plan to move platforms out of the kernel tree to an external
> >> repository and I wanted to do this platform at a time and also only move
> >> each one once. I don't think that is going to happen anytime soon now,
> >> so let's just do your script.
> >>
> >> Can you send me the script and/or a pull request of the resulting
> >> tree based on my soc/dt branch? Everything is merged upstream,
> >> and I think git-merge would handle the remaining merges with any
> >> other changes in mainline.
> > 
> > I've dusted off my script and made a branch[1] with the result.
> > There's just a couple of fixes needed after the script is run (see the
> > top commit). The cross arch includes are all fixed up by the script.
> > dtbs_install maintains a flat install. I compared the number of .dtbs
> > before and after to check the script.
> > 
> > I think the only issue remaining is finalizing the mapping of
> > platforms to subdirs. What I have currently is a mixture of SoC
> > families and vendors. The most notable are all the Freescale/NXP
> > platforms, pxa, socfpga, and stm32. It's not consistent with arm64
> > either. Once that's finalized, I still need to go update MAINTAINERS.
> > 
> > Here's the current mapping:
> > 
> > vendor_map = {
> >     'alphascale' : 'alphascale',
> >     'alpine' : 'alpine',
> >     'artpec' : 'axis',
> >     'axm' : 'lsi',
> >     'cx9' : 'cnxt',
> >     'ecx' : 'calxeda',
> >     'highbank' : 'calxeda',
> >     'ep7' : 'cirrus',
> >     'mxs': 'mxs',
> >     'imx23': 'mxs',
> >     'imx28': 'mxs',
> >     'sun' : 'allwinner',
> >     'imx': 'imx',
> >     'e6' : 'imx',
> >     'e7' : 'imx',
> >     'mba6' : 'imx',
> >     'ls': 'fsl',
> >     'vf': 'fsl',
> 
> If I remember correctly, Vybrid are a bit closer to iMX than to LS
> (Layerscape), but it should be Shawn's call (+Cc).

I would suggest to have all Freescale/NXP platforms in a single
directory, which includes all mxs, imx, fsl ones.

Shawn

> 
> >     'qcom': 'qcom',
> >     'am3' : 'ti',
> >     'am4' : 'ti',
> >     'am5' : 'ti',
> >     'dra' : 'ti',
> >     'keystone' : 'ti',
> >     'omap' : 'ti',
> >     'compulab' : 'ti',
> >     'logicpd' : 'ti',
> >     'elpida' : 'ti',
> >     'motorola' : 'ti',
> >     'twl' : 'ti',
> >     'da' : 'ti',
> >     'dm' : 'ti',
> >     'nspire' : 'nspire',
> >     'armada' : 'marvell',
> >     'dove' : 'marvell',
> >     'kirkwood' : 'marvell',
> >     'orion' : 'marvell',
> >     'mvebu' : 'marvell',
> >     'mmp' : 'marvell',
> >     'berlin' : 'berlin',
> >     'pxa2' : 'pxa',
> >     'pxa3' : 'pxa',
> >     'pxa' : 'marvell',
> >     'arm-' : 'arm',
> >     'integ' : 'arm',
> >     'mps' : 'arm',
> >     've' : 'arm',
> >     'aspeed' : 'aspeed',
> >     'ast2' : 'aspeed',
> >     'facebook' : 'aspeed',
> >     'ibm' : 'aspeed',
> >     'openbmc' : 'aspeed',
> >     'en7' : 'airoha',
> >     'at91' : 'microchip',
> >     'sama' : 'microchip',
> >     'sam9' : 'microchip',
> >     'usb_' : 'microchip',
> >     'tny_' : 'microchip',
> >     'mpa1600' : 'microchip',
> >     'animeo_ip' : 'microchip',
> >     'aks-cdu' : 'microchip',
> >     'ethernut5' : 'microchip',
> >     'evk-pro3' : 'microchip',
> >     'pm9g45' : 'microchip',
> >     'ge86' : 'microchip',
> >     'bcm' : 'brcm',
> >     'exynos' : 'samsung',
> >     's3c' : 'samsung',
> >     's5p' : 'samsung',
> 
> For samsung looks good.
> 
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> >     'gemini' : 'gemini',
> >     'hi3' : 'hisilicon',
> >     'hip' : 'hisilicon',
> >     'hisi' : 'hisilicon',
> >     'sd5' : 'hisilicon',
> >     'hpe' : 'hpe',
> >     'intel': 'intel',
> >     'mt' : 'mediatek',
> >     'meson' : 'meson',
> >     'moxa' : 'moxa',
> >     'mstar' : 'mstar',
> >     'nuvo' : 'nuvoton',
> >     'lpc' : 'lpc',
> >     'lan96' : 'microchip',
> >     'owl' : 'actions',
> >     'ox8' : 'oxsemi',
> >     'rda' : 'rda',
> >     'rtd' : 'realtek',
> >     'r7' : 'renesas',
> >     'r8' : 'renesas',
> >     'r9' : 'renesas',
> >     'emev2' : 'renesas',
> >     'sh73a' : 'renesas',
> >     'gr-' : 'renesas',
> >     'iwg' : 'renesas',
> >     'rk' : 'rockchip',
> >     'rv11' : 'rockchip',
> >     'rockchip' : 'rockchip',
> >     'socfpga' : 'socfpga',
> >     'stm' : 'stm32',
> >     'sti' : 'sti',
> >     'st-pin' : 'sti',
> >     'ste' : 'st-ericsson',
> >     'spear' : 'spear',
> >     'axp' : 'allwinner',
> >     'tegra' : 'nvidia',
> >     'milbeaut' : 'socionext',
> >     'uniph' : 'socionext',
> >     'vt8500' : 'vt8500',
> >     'wm8' : 'vt8500',
> >     'xen' : 'xen',
> >     'zx' : 'zte',
> >     'zynq' : 'xilinx',
> 
> The rest looks good to me, but I don't know half of these :)
> 
> Best regards,
> Krzysztof
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Arnd Bergmann]

On Wed, May 3, 2023, at 03:19, Shawn Guo wrote:
> On Tue, May 02, 2023 at 10:02:03PM +0200, Krzysztof Kozlowski wrote:
>> On 02/05/2023 21:40, Rob Herring wrote:
>> 
>> If I remember correctly, Vybrid are a bit closer to iMX than to LS
>> (Layerscape), but it should be Shawn's call (+Cc).
>
> I would suggest to have all Freescale/NXP platforms in a single
> directory, which includes all mxs, imx, fsl ones.

I'd go with 'nxp' for all of those then, and also include the lpc* ones.

It's fine to stay with historic names if changing it causes problems,
but if we are going to change anyway, then let's call it the current
owner's name. It will get messy again soon enough with the next round
of mergers and acquisitions.

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Linus Walleij]

On Tue, May 2, 2023 at 9:40 PM Rob Herring <robh+dt@kernel.org> wrote:

> I've dusted off my script and made a branch[1] with the result.
> There's just a couple of fixes needed after the script is run (see the
> top commit). The cross arch includes are all fixed up by the script.
> dtbs_install maintains a flat install. I compared the number of .dtbs
> before and after to check the script.
>
> I think the only issue remaining is finalizing the mapping of
> platforms to subdirs. What I have currently is a mixture of SoC
> families and vendors. The most notable are all the Freescale/NXP
> platforms, pxa, socfpga, and stm32. It's not consistent with arm64
> either. Once that's finalized, I still need to go update MAINTAINERS.

I see my nits were fixed like I wanted them, and it's now mostly a
mix of soc and vendor names that make sense so from my point of view:
Acked-by: Linus Walleij <linus.walleij@linaro.org>

NB:
arch/arm64/boot/dts/arm$
vexpress-v2m-rs1.dtsi -> ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi

This still works after the script, yes?

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Rob Herring]

On Tue, May 2, 2023 at 4:19 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Tue, May 2, 2023 at 9:40 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> > I've dusted off my script and made a branch[1] with the result.
> > There's just a couple of fixes needed after the script is run (see the
> > top commit). The cross arch includes are all fixed up by the script.
> > dtbs_install maintains a flat install. I compared the number of .dtbs
> > before and after to check the script.
> >
> > I think the only issue remaining is finalizing the mapping of
> > platforms to subdirs. What I have currently is a mixture of SoC
> > families and vendors. The most notable are all the Freescale/NXP
> > platforms, pxa, socfpga, and stm32. It's not consistent with arm64
> > either. Once that's finalized, I still need to go update MAINTAINERS.
>
> I see my nits were fixed like I wanted them, and it's now mostly a
> mix of soc and vendor names that make sense so from my point of view:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> NB:
> arch/arm64/boot/dts/arm$
> vexpress-v2m-rs1.dtsi -> ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi
>
> This still works after the script, yes?

Yes, because in the script I do:

git grep -l -F "vexpress-v2m-rs1" arch/arm64/boot/dts | xargs perl -p
-i -e "s/vexpress-v2m-rs1/arm\/arm\/vexpress-v2m-rs1/"

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Christian Hewitt]

> On 2 May 2023, at 8:40 pm, Rob Herring <robh+dt@kernel.org> wrote:
> 
> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote:
>> 
>> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
>>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> 
>>>> Does your script also cater for .dts files not matching any pattern,
>>>> but including a .dtsi file that does match a pattern?
>>> 
>>> I assume I built everything after moving, but maybe not...
>>> 
>>> That's all just "details". First, we need agreement on a) moving
>>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've
>>> been stuck on a) for being 'too much churn'.
>> 
>> Sorry for missing most of the discussion last week. The script sounds
>> fine to me, the only reason I didn't want to do this in the past is that
>> we had the plan to move platforms out of the kernel tree to an external
>> repository and I wanted to do this platform at a time and also only move
>> each one once. I don't think that is going to happen anytime soon now,
>> so let's just do your script.
>> 
>> Can you send me the script and/or a pull request of the resulting
>> tree based on my soc/dt branch? Everything is merged upstream,
>> and I think git-merge would handle the remaining merges with any
>> other changes in mainline.
> 
> I've dusted off my script and made a branch[1] with the result.
> There's just a couple of fixes needed after the script is run (see the
> top commit). The cross arch includes are all fixed up by the script.
> dtbs_install maintains a flat install. I compared the number of .dtbs
> before and after to check the script.
> 
> I think the only issue remaining is finalizing the mapping of
> platforms to subdirs. What I have currently is a mixture of SoC
> families and vendors. The most notable are all the Freescale/NXP
> platforms, pxa, socfpga, and stm32. It's not consistent with arm64
> either. Once that's finalized, I still need to go update MAINTAINERS.
> 
> Here's the current mapping:
> 
> vendor_map = {
>    'alphascale' : 'alphascale',
>    'alpine' : 'alpine',
>    'artpec' : 'axis',
>    'axm' : 'lsi',
>    'cx9' : 'cnxt',
>    'ecx' : 'calxeda',
>    'highbank' : 'calxeda',
>    'ep7' : 'cirrus',
>    'mxs': 'mxs',
>    'imx23': 'mxs',
>    'imx28': 'mxs',
>    'sun' : 'allwinner',
>    'imx': 'imx',
>    'e6' : 'imx',
>    'e7' : 'imx',
>    'mba6' : 'imx',
>    'ls': 'fsl',
>    'vf': 'fsl',
>    'qcom': 'qcom',
>    'am3' : 'ti',
>    'am4' : 'ti',
>    'am5' : 'ti',
>    'dra' : 'ti',
>    'keystone' : 'ti',
>    'omap' : 'ti',
>    'compulab' : 'ti',
>    'logicpd' : 'ti',
>    'elpida' : 'ti',
>    'motorola' : 'ti',
>    'twl' : 'ti',
>    'da' : 'ti',
>    'dm' : 'ti',
>    'nspire' : 'nspire',
>    'armada' : 'marvell',
>    'dove' : 'marvell',
>    'kirkwood' : 'marvell',
>    'orion' : 'marvell',
>    'mvebu' : 'marvell',
>    'mmp' : 'marvell',
>    'berlin' : 'berlin',
>    'pxa2' : 'pxa',
>    'pxa3' : 'pxa',
>    'pxa' : 'marvell',
>    'arm-' : 'arm',
>    'integ' : 'arm',
>    'mps' : 'arm',
>    've' : 'arm',
>    'aspeed' : 'aspeed',
>    'ast2' : 'aspeed',
>    'facebook' : 'aspeed',
>    'ibm' : 'aspeed',
>    'openbmc' : 'aspeed',
>    'en7' : 'airoha',
>    'at91' : 'microchip',
>    'sama' : 'microchip',
>    'sam9' : 'microchip',
>    'usb_' : 'microchip',
>    'tny_' : 'microchip',
>    'mpa1600' : 'microchip',
>    'animeo_ip' : 'microchip',
>    'aks-cdu' : 'microchip',
>    'ethernut5' : 'microchip',
>    'evk-pro3' : 'microchip',
>    'pm9g45' : 'microchip',
>    'ge86' : 'microchip',
>    'bcm' : 'brcm',
>    'exynos' : 'samsung',
>    's3c' : 'samsung',
>    's5p' : 'samsung',
>    'gemini' : 'gemini',
>    'hi3' : 'hisilicon',
>    'hip' : 'hisilicon',
>    'hisi' : 'hisilicon',
>    'sd5' : 'hisilicon',
>    'hpe' : 'hpe',
>    'intel': 'intel',
>    'mt' : 'mediatek',
>    'meson' : 'meson',

‘meson’ : ‘amlogic’,

^ to match the SoC vendor name (and arm64)

Christian

>    'moxa' : 'moxa',
>    'mstar' : 'mstar',
>    'nuvo' : 'nuvoton',
>    'lpc' : 'lpc',
>    'lan96' : 'microchip',
>    'owl' : 'actions',
>    'ox8' : 'oxsemi',
>    'rda' : 'rda',
>    'rtd' : 'realtek',
>    'r7' : 'renesas',
>    'r8' : 'renesas',
>    'r9' : 'renesas',
>    'emev2' : 'renesas',
>    'sh73a' : 'renesas',
>    'gr-' : 'renesas',
>    'iwg' : 'renesas',
>    'rk' : 'rockchip',
>    'rv11' : 'rockchip',
>    'rockchip' : 'rockchip',
>    'socfpga' : 'socfpga',
>    'stm' : 'stm32',
>    'sti' : 'sti',
>    'st-pin' : 'sti',
>    'ste' : 'st-ericsson',
>    'spear' : 'spear',
>    'axp' : 'allwinner',
>    'tegra' : 'nvidia',
>    'milbeaut' : 'socionext',
>    'uniph' : 'socionext',
>    'vt8500' : 'vt8500',
>    'wm8' : 'vt8500',
>    'xen' : 'xen',
>    'zx' : 'zte',
>    'zynq' : 'xilinx',
> }
> 
> Rob
> 
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git arm-dts-move-v2
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Neil Armstrong]

On 03/05/2023 00:01, Christian Hewitt wrote:
> 
> 
>> On 2 May 2023, at 8:40 pm, Rob Herring <robh+dt@kernel.org> wrote:
>>
>> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote:
>>>
>>> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
>>>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>>
>>>>> Does your script also cater for .dts files not matching any pattern,
>>>>> but including a .dtsi file that does match a pattern?
>>>>
>>>> I assume I built everything after moving, but maybe not...
>>>>
>>>> That's all just "details". First, we need agreement on a) moving
>>>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've
>>>> been stuck on a) for being 'too much churn'.
>>>
>>> Sorry for missing most of the discussion last week. The script sounds
>>> fine to me, the only reason I didn't want to do this in the past is that
>>> we had the plan to move platforms out of the kernel tree to an external
>>> repository and I wanted to do this platform at a time and also only move
>>> each one once. I don't think that is going to happen anytime soon now,
>>> so let's just do your script.
>>>
>>> Can you send me the script and/or a pull request of the resulting
>>> tree based on my soc/dt branch? Everything is merged upstream,
>>> and I think git-merge would handle the remaining merges with any
>>> other changes in mainline.
>>
>> I've dusted off my script and made a branch[1] with the result.
>> There's just a couple of fixes needed after the script is run (see the
>> top commit). The cross arch includes are all fixed up by the script.
>> dtbs_install maintains a flat install. I compared the number of .dtbs
>> before and after to check the script.
>>
>> I think the only issue remaining is finalizing the mapping of
>> platforms to subdirs. What I have currently is a mixture of SoC
>> families and vendors. The most notable are all the Freescale/NXP
>> platforms, pxa, socfpga, and stm32. It's not consistent with arm64
>> either. Once that's finalized, I still need to go update MAINTAINERS.
>>
>> Here's the current mapping:
>>
>> vendor_map = {
>>     'alphascale' : 'alphascale',
>>     'alpine' : 'alpine',
>>     'artpec' : 'axis',
>>     'axm' : 'lsi',
>>     'cx9' : 'cnxt',
>>     'ecx' : 'calxeda',
>>     'highbank' : 'calxeda',
>>     'ep7' : 'cirrus',
>>     'mxs': 'mxs',
>>     'imx23': 'mxs',
>>     'imx28': 'mxs',
>>     'sun' : 'allwinner',
>>     'imx': 'imx',
>>     'e6' : 'imx',
>>     'e7' : 'imx',
>>     'mba6' : 'imx',
>>     'ls': 'fsl',
>>     'vf': 'fsl',
>>     'qcom': 'qcom',
>>     'am3' : 'ti',
>>     'am4' : 'ti',
>>     'am5' : 'ti',
>>     'dra' : 'ti',
>>     'keystone' : 'ti',
>>     'omap' : 'ti',
>>     'compulab' : 'ti',
>>     'logicpd' : 'ti',
>>     'elpida' : 'ti',
>>     'motorola' : 'ti',
>>     'twl' : 'ti',
>>     'da' : 'ti',
>>     'dm' : 'ti',
>>     'nspire' : 'nspire',
>>     'armada' : 'marvell',
>>     'dove' : 'marvell',
>>     'kirkwood' : 'marvell',
>>     'orion' : 'marvell',
>>     'mvebu' : 'marvell',
>>     'mmp' : 'marvell',
>>     'berlin' : 'berlin',
>>     'pxa2' : 'pxa',
>>     'pxa3' : 'pxa',
>>     'pxa' : 'marvell',
>>     'arm-' : 'arm',
>>     'integ' : 'arm',
>>     'mps' : 'arm',
>>     've' : 'arm',
>>     'aspeed' : 'aspeed',
>>     'ast2' : 'aspeed',
>>     'facebook' : 'aspeed',
>>     'ibm' : 'aspeed',
>>     'openbmc' : 'aspeed',
>>     'en7' : 'airoha',
>>     'at91' : 'microchip',
>>     'sama' : 'microchip',
>>     'sam9' : 'microchip',
>>     'usb_' : 'microchip',
>>     'tny_' : 'microchip',
>>     'mpa1600' : 'microchip',
>>     'animeo_ip' : 'microchip',
>>     'aks-cdu' : 'microchip',
>>     'ethernut5' : 'microchip',
>>     'evk-pro3' : 'microchip',
>>     'pm9g45' : 'microchip',
>>     'ge86' : 'microchip',
>>     'bcm' : 'brcm',
>>     'exynos' : 'samsung',
>>     's3c' : 'samsung',
>>     's5p' : 'samsung',
>>     'gemini' : 'gemini',
>>     'hi3' : 'hisilicon',
>>     'hip' : 'hisilicon',
>>     'hisi' : 'hisilicon',
>>     'sd5' : 'hisilicon',
>>     'hpe' : 'hpe',
>>     'intel': 'intel',
>>     'mt' : 'mediatek',
>>     'meson' : 'meson',
> 
> ‘meson’ : ‘amlogic’,
> 
> ^ to match the SoC vendor name (and arm64)

Ack we're trying to get rid of meson, so it would be time.

Neil

> 
> Christian
> 
>>     'moxa' : 'moxa',
>>     'mstar' : 'mstar',
>>     'nuvo' : 'nuvoton',
>>     'lpc' : 'lpc',
>>     'lan96' : 'microchip',
>>     'owl' : 'actions',
>>     'ox8' : 'oxsemi',
>>     'rda' : 'rda',
>>     'rtd' : 'realtek',
>>     'r7' : 'renesas',
>>     'r8' : 'renesas',
>>     'r9' : 'renesas',
>>     'emev2' : 'renesas',
>>     'sh73a' : 'renesas',
>>     'gr-' : 'renesas',
>>     'iwg' : 'renesas',
>>     'rk' : 'rockchip',
>>     'rv11' : 'rockchip',
>>     'rockchip' : 'rockchip',
>>     'socfpga' : 'socfpga',
>>     'stm' : 'stm32',
>>     'sti' : 'sti',
>>     'st-pin' : 'sti',
>>     'ste' : 'st-ericsson',
>>     'spear' : 'spear',
>>     'axp' : 'allwinner',
>>     'tegra' : 'nvidia',
>>     'milbeaut' : 'socionext',
>>     'uniph' : 'socionext',
>>     'vt8500' : 'vt8500',
>>     'wm8' : 'vt8500',
>>     'xen' : 'xen',
>>     'zx' : 'zte',
>>     'zynq' : 'xilinx',
>> }
>>
>> Rob
>>
>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git arm-dts-move-v2
>>
>> _______________________________________________
>> linux-amlogic mailing list
>> linux-amlogic@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Dmitry Baryshkov]

On 02/05/2023 22:40, Rob Herring wrote:
> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
>>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>
>>>> Does your script also cater for .dts files not matching any pattern,
>>>> but including a .dtsi file that does match a pattern?
>>>
>>> I assume I built everything after moving, but maybe not...
>>>
>>> That's all just "details". First, we need agreement on a) moving
>>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've
>>> been stuck on a) for being 'too much churn'.
>>
>> Sorry for missing most of the discussion last week. The script sounds
>> fine to me, the only reason I didn't want to do this in the past is that
>> we had the plan to move platforms out of the kernel tree to an external
>> repository and I wanted to do this platform at a time and also only move
>> each one once. I don't think that is going to happen anytime soon now,
>> so let's just do your script.
>>
>> Can you send me the script and/or a pull request of the resulting
>> tree based on my soc/dt branch? Everything is merged upstream,
>> and I think git-merge would handle the remaining merges with any
>> other changes in mainline.
> 
> I've dusted off my script and made a branch[1] with the result.
> There's just a couple of fixes needed after the script is run (see the
> top commit). The cross arch includes are all fixed up by the script.
> dtbs_install maintains a flat install. I compared the number of .dtbs
> before and after to check the script.
> 
> I think the only issue remaining is finalizing the mapping of
> platforms to subdirs. What I have currently is a mixture of SoC
> families and vendors. The most notable are all the Freescale/NXP
> platforms, pxa, socfpga, and stm32. It's not consistent with arm64
> either. Once that's finalized, I still need to go update MAINTAINERS.
> 
> Here's the current mapping:
> 
> vendor_map = {
>      'alphascale' : 'alphascale',
>      'alpine' : 'alpine',
>      'artpec' : 'axis',
>      'axm' : 'lsi',
>      'cx9' : 'cnxt',
>      'ecx' : 'calxeda',
>      'highbank' : 'calxeda',
>      'ep7' : 'cirrus',
>      'mxs': 'mxs',
>      'imx23': 'mxs',
>      'imx28': 'mxs',
>      'sun' : 'allwinner',
>      'imx': 'imx',
>      'e6' : 'imx',
>      'e7' : 'imx',
>      'mba6' : 'imx',
>      'ls': 'fsl',
>      'vf': 'fsl',
>      'qcom': 'qcom',
>      'am3' : 'ti',
>      'am4' : 'ti',
>      'am5' : 'ti',
>      'dra' : 'ti',
>      'keystone' : 'ti',
>      'omap' : 'ti',
>      'compulab' : 'ti',
>      'logicpd' : 'ti',
>      'elpida' : 'ti',
>      'motorola' : 'ti',
>      'twl' : 'ti',
>      'da' : 'ti',
>      'dm' : 'ti',
>      'nspire' : 'nspire',
>      'armada' : 'marvell',
>      'dove' : 'marvell',
>      'kirkwood' : 'marvell',
>      'orion' : 'marvell',
>      'mvebu' : 'marvell',
>      'mmp' : 'marvell',
>      'berlin' : 'berlin',
>      'pxa2' : 'pxa',
>      'pxa3' : 'pxa',
>      'pxa' : 'marvell',

I'd question if it makes sense to split the pxa line. Yes, it was sold 
by Intel to Marvell, but IIRC the devices still had some inheritance. 
So, if we have the 'pxa' subdir, I'd move Marvell PXAs to that dir too.

>      'arm-' : 'arm',
>      'integ' : 'arm',
>      'mps' : 'arm',
>      've' : 'arm',
>      'aspeed' : 'aspeed',
>      'ast2' : 'aspeed',
>      'facebook' : 'aspeed',
>      'ibm' : 'aspeed',
>      'openbmc' : 'aspeed',
>      'en7' : 'airoha',
>      'at91' : 'microchip',
>      'sama' : 'microchip',
>      'sam9' : 'microchip',
>      'usb_' : 'microchip',
>      'tny_' : 'microchip',
>      'mpa1600' : 'microchip',
>      'animeo_ip' : 'microchip',
>      'aks-cdu' : 'microchip',
>      'ethernut5' : 'microchip',
>      'evk-pro3' : 'microchip',
>      'pm9g45' : 'microchip',
>      'ge86' : 'microchip',
>      'bcm' : 'brcm',
>      'exynos' : 'samsung',
>      's3c' : 'samsung',
>      's5p' : 'samsung',
>      'gemini' : 'gemini',
>      'hi3' : 'hisilicon',
>      'hip' : 'hisilicon',
>      'hisi' : 'hisilicon',
>      'sd5' : 'hisilicon',
>      'hpe' : 'hpe',
>      'intel': 'intel',
>      'mt' : 'mediatek',
>      'meson' : 'meson',
>      'moxa' : 'moxa',
>      'mstar' : 'mstar',
>      'nuvo' : 'nuvoton',
>      'lpc' : 'lpc',
>      'lan96' : 'microchip',
>      'owl' : 'actions',
>      'ox8' : 'oxsemi',
>      'rda' : 'rda',
>      'rtd' : 'realtek',
>      'r7' : 'renesas',
>      'r8' : 'renesas',
>      'r9' : 'renesas',
>      'emev2' : 'renesas',
>      'sh73a' : 'renesas',
>      'gr-' : 'renesas',
>      'iwg' : 'renesas',
>      'rk' : 'rockchip',
>      'rv11' : 'rockchip',
>      'rockchip' : 'rockchip',
>      'socfpga' : 'socfpga',
>      'stm' : 'stm32',
>      'sti' : 'sti',
>      'st-pin' : 'sti',
>      'ste' : 'st-ericsson',
>      'spear' : 'spear',
>      'axp' : 'allwinner',
>      'tegra' : 'nvidia',
>      'milbeaut' : 'socionext',
>      'uniph' : 'socionext',
>      'vt8500' : 'vt8500',
>      'wm8' : 'vt8500',
>      'xen' : 'xen',
>      'zx' : 'zte',
>      'zynq' : 'xilinx',
> }
> 
> Rob
> 
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git arm-dts-move-v2

-- 
With best wishes
Dmitry


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Rob Herring]

On Tue, May 2, 2023 at 5:52 PM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On 02/05/2023 22:40, Rob Herring wrote:
> > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
> >>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >>>
> >>>> Does your script also cater for .dts files not matching any pattern,
> >>>> but including a .dtsi file that does match a pattern?
> >>>
> >>> I assume I built everything after moving, but maybe not...
> >>>
> >>> That's all just "details". First, we need agreement on a) moving
> >>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've
> >>> been stuck on a) for being 'too much churn'.
> >>
> >> Sorry for missing most of the discussion last week. The script sounds
> >> fine to me, the only reason I didn't want to do this in the past is that
> >> we had the plan to move platforms out of the kernel tree to an external
> >> repository and I wanted to do this platform at a time and also only move
> >> each one once. I don't think that is going to happen anytime soon now,
> >> so let's just do your script.
> >>
> >> Can you send me the script and/or a pull request of the resulting
> >> tree based on my soc/dt branch? Everything is merged upstream,
> >> and I think git-merge would handle the remaining merges with any
> >> other changes in mainline.
> >
> > I've dusted off my script and made a branch[1] with the result.
> > There's just a couple of fixes needed after the script is run (see the
> > top commit). The cross arch includes are all fixed up by the script.
> > dtbs_install maintains a flat install. I compared the number of .dtbs
> > before and after to check the script.
> >
> > I think the only issue remaining is finalizing the mapping of
> > platforms to subdirs. What I have currently is a mixture of SoC
> > families and vendors. The most notable are all the Freescale/NXP
> > platforms, pxa, socfpga, and stm32. It's not consistent with arm64
> > either. Once that's finalized, I still need to go update MAINTAINERS.
> >
> > Here's the current mapping:
> >
> > vendor_map = {
> >      'alphascale' : 'alphascale',
> >      'alpine' : 'alpine',
> >      'artpec' : 'axis',
> >      'axm' : 'lsi',
> >      'cx9' : 'cnxt',
> >      'ecx' : 'calxeda',
> >      'highbank' : 'calxeda',
> >      'ep7' : 'cirrus',
> >      'mxs': 'mxs',
> >      'imx23': 'mxs',
> >      'imx28': 'mxs',
> >      'sun' : 'allwinner',
> >      'imx': 'imx',
> >      'e6' : 'imx',
> >      'e7' : 'imx',
> >      'mba6' : 'imx',
> >      'ls': 'fsl',
> >      'vf': 'fsl',
> >      'qcom': 'qcom',
> >      'am3' : 'ti',
> >      'am4' : 'ti',
> >      'am5' : 'ti',
> >      'dra' : 'ti',
> >      'keystone' : 'ti',
> >      'omap' : 'ti',
> >      'compulab' : 'ti',
> >      'logicpd' : 'ti',
> >      'elpida' : 'ti',
> >      'motorola' : 'ti',
> >      'twl' : 'ti',
> >      'da' : 'ti',
> >      'dm' : 'ti',
> >      'nspire' : 'nspire',
> >      'armada' : 'marvell',
> >      'dove' : 'marvell',
> >      'kirkwood' : 'marvell',
> >      'orion' : 'marvell',
> >      'mvebu' : 'marvell',
> >      'mmp' : 'marvell',
> >      'berlin' : 'berlin',
> >      'pxa2' : 'pxa',
> >      'pxa3' : 'pxa',
> >      'pxa' : 'marvell',
>
> I'd question if it makes sense to split the pxa line. Yes, it was sold
> by Intel to Marvell, but IIRC the devices still had some inheritance.
> So, if we have the 'pxa' subdir, I'd move Marvell PXAs to that dir too.

I think I probably split it because it was different maintainers.
Though it doesn't look like pxa168 or pxa910 have any maintainer. They
are a mixture of pxa and mmp I think.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Arnd Bergmann]

On Wed, May 3, 2023, at 03:17, Rob Herring wrote:
> On Tue, May 2, 2023 at 5:52 PM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
>> On 02/05/2023 22:40, Rob Herring wrote:
>> >      'berlin' : 'berlin',
>> >      'pxa2' : 'pxa',
>> >      'pxa3' : 'pxa',
>> >      'pxa' : 'marvell',
>>
>> I'd question if it makes sense to split the pxa line. Yes, it was sold
>> by Intel to Marvell, but IIRC the devices still had some inheritance.
>> So, if we have the 'pxa' subdir, I'd move Marvell PXAs to that dir too.
>
> I think I probably split it because it was different maintainers.
> Though it doesn't look like pxa168 or pxa910 have any maintainer. They
> are a mixture of pxa and mmp I think.

I think the original split here is probably the best we can do,
but there is no good way to do it because of the confusing naming
and the problem that there is no clear line between pxa and mmp.
As far as I can tell, the release timeline was:

Intel pxa2xx (mach-pxa, xscale, still exists)
Intel pxa3xx (mach-pxa, xscale, still exists)
Intel pxa90x (never merged)
Marvell pxa93x (mach-pxa, xscale, removed in Linux-6.3, no DT)
Marvell pxa92x (never merged)
Marvell pxa91x (mach-mmp, pj1, still exists)
Marvell pxa168 (mach-mmp, pj1, still exists)
Marvell pxa95x (mach-pxa, pj4, long gone)
Marvell pxa688 (mach-mmp, pj4, known as mmp2)

So with pxa93x out of the picture, we can simplify it as using
'pxa' as the name for all the above chips with an Intel XScale
core, and 'marvell' for all the other ones that have a Marvell
core and exist in mach-mmp.

     Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Dmitry Baryshkov]

On Wed, 3 May 2023 at 13:39, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wed, May 3, 2023, at 03:17, Rob Herring wrote:
> > On Tue, May 2, 2023 at 5:52 PM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> >> On 02/05/2023 22:40, Rob Herring wrote:
> >> >      'berlin' : 'berlin',
> >> >      'pxa2' : 'pxa',
> >> >      'pxa3' : 'pxa',
> >> >      'pxa' : 'marvell',
> >>
> >> I'd question if it makes sense to split the pxa line. Yes, it was sold
> >> by Intel to Marvell, but IIRC the devices still had some inheritance.
> >> So, if we have the 'pxa' subdir, I'd move Marvell PXAs to that dir too.
> >
> > I think I probably split it because it was different maintainers.
> > Though it doesn't look like pxa168 or pxa910 have any maintainer. They
> > are a mixture of pxa and mmp I think.
>
> I think the original split here is probably the best we can do,
> but there is no good way to do it because of the confusing naming
> and the problem that there is no clear line between pxa and mmp.
> As far as I can tell, the release timeline was:
>
> Intel pxa2xx (mach-pxa, xscale, still exists)
> Intel pxa3xx (mach-pxa, xscale, still exists)
> Intel pxa90x (never merged)
> Marvell pxa93x (mach-pxa, xscale, removed in Linux-6.3, no DT)
> Marvell pxa92x (never merged)
> Marvell pxa91x (mach-mmp, pj1, still exists)
> Marvell pxa168 (mach-mmp, pj1, still exists)
> Marvell pxa95x (mach-pxa, pj4, long gone)
> Marvell pxa688 (mach-mmp, pj4, known as mmp2)
>
> So with pxa93x out of the picture, we can simplify it as using
> 'pxa' as the name for all the above chips with an Intel XScale
> core, and 'marvell' for all the other ones that have a Marvell
> core and exist in mach-mmp.

Should it be 'intel' for pxa[23]xx then?

>
>      Arnd



-- 
With best wishes
Dmitry

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Arnd Bergmann]

On Wed, May 3, 2023, at 14:13, Dmitry Baryshkov wrote:
> On Wed, 3 May 2023 at 13:39, Arnd Bergmann <arnd@arndb.de> wrote:

>> So with pxa93x out of the picture, we can simplify it as using
>> 'pxa' as the name for all the above chips with an Intel XScale
>> core, and 'marvell' for all the other ones that have a Marvell
>> core and exist in mach-mmp.
>
> Should it be 'intel' for pxa[23]xx then?

Probably yes, that would put it next to ixp4xx, which makes
a lot of sense (same vintage, same cpu core), though it is
a bit funny to have these together with lsi axxia and
altera socfpga, both of which are also in the intel
directory. socfpga is of course the only one that anybody
at Intel cares about these days.

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Rob Herring]

On Wed, May 3, 2023 at 7:19 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wed, May 3, 2023, at 14:13, Dmitry Baryshkov wrote:
> > On Wed, 3 May 2023 at 13:39, Arnd Bergmann <arnd@arndb.de> wrote:
>
> >> So with pxa93x out of the picture, we can simplify it as using
> >> 'pxa' as the name for all the above chips with an Intel XScale
> >> core, and 'marvell' for all the other ones that have a Marvell
> >> core and exist in mach-mmp.
> >
> > Should it be 'intel' for pxa[23]xx then?
>
> Probably yes, that would put it next to ixp4xx, which makes
> a lot of sense (same vintage, same cpu core), though it is
> a bit funny to have these together with lsi axxia and
> altera socfpga, both of which are also in the intel
> directory. socfpga is of course the only one that anybody
> at Intel cares about these days.

We could do a second level of directories here:

intel/pxa/
intel/ixp/
intel/socfpga/

arm64 broadcom dts files are structured that way.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Arnd Bergmann]

On Wed, May 3, 2023, at 15:16, Rob Herring wrote:

> We could do a second level of directories here:

Works for me, but at that point, I'd really also want to do it
for nxp with its five or more product lines (mxs, imx, lpc,
s32, layerscape, vybrid)

> intel/pxa/
> intel/ixp/
> intel/socfpga/

and intel/axxia I guess.

     Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Linus Walleij]

On Wed, May 3, 2023 at 10:37 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, May 3, 2023, at 15:16, Rob Herring wrote:
>
> > We could do a second level of directories here:
>
> Works for me, but at that point, I'd really also want to do it
> for nxp with its five or more product lines (mxs, imx, lpc,
> s32, layerscape, vybrid)
>
> > intel/pxa/
> > intel/ixp/
> > intel/socfpga/
>
> and intel/axxia I guess.

This looks neat. I like it.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Rob Herring]

On Wed, May 3, 2023 at 3:37 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wed, May 3, 2023, at 15:16, Rob Herring wrote:
>
> > We could do a second level of directories here:
>
> Works for me, but at that point, I'd really also want to do it
> for nxp with its five or more product lines (mxs, imx, lpc,
> s32, layerscape, vybrid)

And marvell, microchip(lan96), ti, and broadcom probably. I think I
withdraw my suggestion...

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Florian Fainelli]

On 5/2/23 12:40, Rob Herring wrote:
> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
>>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>
>>>> Does your script also cater for .dts files not matching any pattern,
>>>> but including a .dtsi file that does match a pattern?
>>>
>>> I assume I built everything after moving, but maybe not...
>>>
>>> That's all just "details". First, we need agreement on a) moving
>>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've
>>> been stuck on a) for being 'too much churn'.
>>
>> Sorry for missing most of the discussion last week. The script sounds
>> fine to me, the only reason I didn't want to do this in the past is that
>> we had the plan to move platforms out of the kernel tree to an external
>> repository and I wanted to do this platform at a time and also only move
>> each one once. I don't think that is going to happen anytime soon now,
>> so let's just do your script.
>>
>> Can you send me the script and/or a pull request of the resulting
>> tree based on my soc/dt branch? Everything is merged upstream,
>> and I think git-merge would handle the remaining merges with any
>> other changes in mainline.
> 
> I've dusted off my script and made a branch[1] with the result.
> There's just a couple of fixes needed after the script is run (see the
> top commit). The cross arch includes are all fixed up by the script.
> dtbs_install maintains a flat install. I compared the number of .dtbs
> before and after to check the script.
> 
> I think the only issue remaining is finalizing the mapping of
> platforms to subdirs. What I have currently is a mixture of SoC
> families and vendors. The most notable are all the Freescale/NXP
> platforms, pxa, socfpga, and stm32. It's not consistent with arm64
> either. Once that's finalized, I still need to go update MAINTAINERS.
> 
> Here's the current mapping:
> 
> vendor_map = {
>      'alphascale' : 'alphascale',
>      'alpine' : 'alpine',
>      'artpec' : 'axis',
>      'axm' : 'lsi',
>      'cx9' : 'cnxt',
>      'ecx' : 'calxeda',
>      'highbank' : 'calxeda',
>      'ep7' : 'cirrus',
>      'mxs': 'mxs',
>      'imx23': 'mxs',
>      'imx28': 'mxs',
>      'sun' : 'allwinner',
>      'imx': 'imx',
>      'e6' : 'imx',
>      'e7' : 'imx',
>      'mba6' : 'imx',
>      'ls': 'fsl',
>      'vf': 'fsl',
>      'qcom': 'qcom',
>      'am3' : 'ti',
>      'am4' : 'ti',
>      'am5' : 'ti',
>      'dra' : 'ti',
>      'keystone' : 'ti',
>      'omap' : 'ti',
>      'compulab' : 'ti',
>      'logicpd' : 'ti',
>      'elpida' : 'ti',
>      'motorola' : 'ti',
>      'twl' : 'ti',
>      'da' : 'ti',
>      'dm' : 'ti',
>      'nspire' : 'nspire',
>      'armada' : 'marvell',
>      'dove' : 'marvell',
>      'kirkwood' : 'marvell',
>      'orion' : 'marvell',
>      'mvebu' : 'marvell',
>      'mmp' : 'marvell',
>      'berlin' : 'berlin',
>      'pxa2' : 'pxa',
>      'pxa3' : 'pxa',
>      'pxa' : 'marvell',
>      'arm-' : 'arm',
>      'integ' : 'arm',
>      'mps' : 'arm',
>      've' : 'arm',
>      'aspeed' : 'aspeed',
>      'ast2' : 'aspeed',
>      'facebook' : 'aspeed',
>      'ibm' : 'aspeed',
>      'openbmc' : 'aspeed',
>      'en7' : 'airoha',
>      'at91' : 'microchip',
>      'sama' : 'microchip',
>      'sam9' : 'microchip',
>      'usb_' : 'microchip',
>      'tny_' : 'microchip',
>      'mpa1600' : 'microchip',
>      'animeo_ip' : 'microchip',
>      'aks-cdu' : 'microchip',
>      'ethernut5' : 'microchip',
>      'evk-pro3' : 'microchip',
>      'pm9g45' : 'microchip',
>      'ge86' : 'microchip',
>      'bcm' : 'brcm',

How about we use 'broadcom' here, to follow what arm64 does? I could 
rename arch/mips/boot/dts/brcm to arch/mips/boot/dts/broadcom for 
consistency, too?
-- 
Florian


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Rob Herring]

On Tue, May 2, 2023 at 6:02 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 5/2/23 12:40, Rob Herring wrote:
> > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
> >>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >>>
> >>>> Does your script also cater for .dts files not matching any pattern,
> >>>> but including a .dtsi file that does match a pattern?
> >>>
> >>> I assume I built everything after moving, but maybe not...
> >>>
> >>> That's all just "details". First, we need agreement on a) moving
> >>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've
> >>> been stuck on a) for being 'too much churn'.
> >>
> >> Sorry for missing most of the discussion last week. The script sounds
> >> fine to me, the only reason I didn't want to do this in the past is that
> >> we had the plan to move platforms out of the kernel tree to an external
> >> repository and I wanted to do this platform at a time and also only move
> >> each one once. I don't think that is going to happen anytime soon now,
> >> so let's just do your script.
> >>
> >> Can you send me the script and/or a pull request of the resulting
> >> tree based on my soc/dt branch? Everything is merged upstream,
> >> and I think git-merge would handle the remaining merges with any
> >> other changes in mainline.
> >
> > I've dusted off my script and made a branch[1] with the result.
> > There's just a couple of fixes needed after the script is run (see the
> > top commit). The cross arch includes are all fixed up by the script.
> > dtbs_install maintains a flat install. I compared the number of .dtbs
> > before and after to check the script.
> >
> > I think the only issue remaining is finalizing the mapping of
> > platforms to subdirs. What I have currently is a mixture of SoC
> > families and vendors. The most notable are all the Freescale/NXP
> > platforms, pxa, socfpga, and stm32. It's not consistent with arm64
> > either. Once that's finalized, I still need to go update MAINTAINERS.
> >
> > Here's the current mapping:
> >
> > vendor_map = {
> >      'alphascale' : 'alphascale',
> >      'alpine' : 'alpine',
> >      'artpec' : 'axis',
> >      'axm' : 'lsi',
> >      'cx9' : 'cnxt',
> >      'ecx' : 'calxeda',
> >      'highbank' : 'calxeda',
> >      'ep7' : 'cirrus',
> >      'mxs': 'mxs',
> >      'imx23': 'mxs',
> >      'imx28': 'mxs',
> >      'sun' : 'allwinner',
> >      'imx': 'imx',
> >      'e6' : 'imx',
> >      'e7' : 'imx',
> >      'mba6' : 'imx',
> >      'ls': 'fsl',
> >      'vf': 'fsl',
> >      'qcom': 'qcom',
> >      'am3' : 'ti',
> >      'am4' : 'ti',
> >      'am5' : 'ti',
> >      'dra' : 'ti',
> >      'keystone' : 'ti',
> >      'omap' : 'ti',
> >      'compulab' : 'ti',
> >      'logicpd' : 'ti',
> >      'elpida' : 'ti',
> >      'motorola' : 'ti',
> >      'twl' : 'ti',
> >      'da' : 'ti',
> >      'dm' : 'ti',
> >      'nspire' : 'nspire',
> >      'armada' : 'marvell',
> >      'dove' : 'marvell',
> >      'kirkwood' : 'marvell',
> >      'orion' : 'marvell',
> >      'mvebu' : 'marvell',
> >      'mmp' : 'marvell',
> >      'berlin' : 'berlin',
> >      'pxa2' : 'pxa',
> >      'pxa3' : 'pxa',
> >      'pxa' : 'marvell',
> >      'arm-' : 'arm',
> >      'integ' : 'arm',
> >      'mps' : 'arm',
> >      've' : 'arm',
> >      'aspeed' : 'aspeed',
> >      'ast2' : 'aspeed',
> >      'facebook' : 'aspeed',
> >      'ibm' : 'aspeed',
> >      'openbmc' : 'aspeed',
> >      'en7' : 'airoha',
> >      'at91' : 'microchip',
> >      'sama' : 'microchip',
> >      'sam9' : 'microchip',
> >      'usb_' : 'microchip',
> >      'tny_' : 'microchip',
> >      'mpa1600' : 'microchip',
> >      'animeo_ip' : 'microchip',
> >      'aks-cdu' : 'microchip',
> >      'ethernut5' : 'microchip',
> >      'evk-pro3' : 'microchip',
> >      'pm9g45' : 'microchip',
> >      'ge86' : 'microchip',
> >      'bcm' : 'brcm',
>
> How about we use 'broadcom' here, to follow what arm64 does? I could
> rename arch/mips/boot/dts/brcm to arch/mips/boot/dts/broadcom for
> consistency, too?

Okay, though if starting clean I'd somewhat prefer to use the vendor
prefix. I guess since arm and arm64 share dtsi files, they should
match.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Florian Fainelli]

On 5/2/23 18:04, Rob Herring wrote:
> On Tue, May 2, 2023 at 6:02 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> On 5/2/23 12:40, Rob Herring wrote:
>>> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote:
>>>>
>>>> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
>>>>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>>>
>>>>>> Does your script also cater for .dts files not matching any pattern,
>>>>>> but including a .dtsi file that does match a pattern?
>>>>>
>>>>> I assume I built everything after moving, but maybe not...
>>>>>
>>>>> That's all just "details". First, we need agreement on a) moving
>>>>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've
>>>>> been stuck on a) for being 'too much churn'.
>>>>
>>>> Sorry for missing most of the discussion last week. The script sounds
>>>> fine to me, the only reason I didn't want to do this in the past is that
>>>> we had the plan to move platforms out of the kernel tree to an external
>>>> repository and I wanted to do this platform at a time and also only move
>>>> each one once. I don't think that is going to happen anytime soon now,
>>>> so let's just do your script.
>>>>
>>>> Can you send me the script and/or a pull request of the resulting
>>>> tree based on my soc/dt branch? Everything is merged upstream,
>>>> and I think git-merge would handle the remaining merges with any
>>>> other changes in mainline.
>>>
>>> I've dusted off my script and made a branch[1] with the result.
>>> There's just a couple of fixes needed after the script is run (see the
>>> top commit). The cross arch includes are all fixed up by the script.
>>> dtbs_install maintains a flat install. I compared the number of .dtbs
>>> before and after to check the script.
>>>
>>> I think the only issue remaining is finalizing the mapping of
>>> platforms to subdirs. What I have currently is a mixture of SoC
>>> families and vendors. The most notable are all the Freescale/NXP
>>> platforms, pxa, socfpga, and stm32. It's not consistent with arm64
>>> either. Once that's finalized, I still need to go update MAINTAINERS.
>>>
>>> Here's the current mapping:
>>>
>>> vendor_map = {
>>>       'alphascale' : 'alphascale',
>>>       'alpine' : 'alpine',
>>>       'artpec' : 'axis',
>>>       'axm' : 'lsi',
>>>       'cx9' : 'cnxt',
>>>       'ecx' : 'calxeda',
>>>       'highbank' : 'calxeda',
>>>       'ep7' : 'cirrus',
>>>       'mxs': 'mxs',
>>>       'imx23': 'mxs',
>>>       'imx28': 'mxs',
>>>       'sun' : 'allwinner',
>>>       'imx': 'imx',
>>>       'e6' : 'imx',
>>>       'e7' : 'imx',
>>>       'mba6' : 'imx',
>>>       'ls': 'fsl',
>>>       'vf': 'fsl',
>>>       'qcom': 'qcom',
>>>       'am3' : 'ti',
>>>       'am4' : 'ti',
>>>       'am5' : 'ti',
>>>       'dra' : 'ti',
>>>       'keystone' : 'ti',
>>>       'omap' : 'ti',
>>>       'compulab' : 'ti',
>>>       'logicpd' : 'ti',
>>>       'elpida' : 'ti',
>>>       'motorola' : 'ti',
>>>       'twl' : 'ti',
>>>       'da' : 'ti',
>>>       'dm' : 'ti',
>>>       'nspire' : 'nspire',
>>>       'armada' : 'marvell',
>>>       'dove' : 'marvell',
>>>       'kirkwood' : 'marvell',
>>>       'orion' : 'marvell',
>>>       'mvebu' : 'marvell',
>>>       'mmp' : 'marvell',
>>>       'berlin' : 'berlin',
>>>       'pxa2' : 'pxa',
>>>       'pxa3' : 'pxa',
>>>       'pxa' : 'marvell',
>>>       'arm-' : 'arm',
>>>       'integ' : 'arm',
>>>       'mps' : 'arm',
>>>       've' : 'arm',
>>>       'aspeed' : 'aspeed',
>>>       'ast2' : 'aspeed',
>>>       'facebook' : 'aspeed',
>>>       'ibm' : 'aspeed',
>>>       'openbmc' : 'aspeed',
>>>       'en7' : 'airoha',
>>>       'at91' : 'microchip',
>>>       'sama' : 'microchip',
>>>       'sam9' : 'microchip',
>>>       'usb_' : 'microchip',
>>>       'tny_' : 'microchip',
>>>       'mpa1600' : 'microchip',
>>>       'animeo_ip' : 'microchip',
>>>       'aks-cdu' : 'microchip',
>>>       'ethernut5' : 'microchip',
>>>       'evk-pro3' : 'microchip',
>>>       'pm9g45' : 'microchip',
>>>       'ge86' : 'microchip',
>>>       'bcm' : 'brcm',
>>
>> How about we use 'broadcom' here, to follow what arm64 does? I could
>> rename arch/mips/boot/dts/brcm to arch/mips/boot/dts/broadcom for
>> consistency, too?
> 
> Okay, though if starting clean I'd somewhat prefer to use the vendor
> prefix. I guess since arm and arm64 share dtsi files, they should
> match.

Sounds good to me, let's go with "brcm" then.
-- 
Florian


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Tony Lindgren]

* Rob Herring <robh+dt@kernel.org> [230502 19:40]:
> I've dusted off my script and made a branch[1] with the result.
> There's just a couple of fixes needed after the script is run (see the
> top commit). The cross arch includes are all fixed up by the script.
> dtbs_install maintains a flat install. I compared the number of .dtbs
> before and after to check the script.
...

> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git arm-dts-move-v2

Looks good to me, thanks for doing this.

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Geert Uytterhoeven]

Hi Rob,

On Tue, May 2, 2023 at 9:40 PM Rob Herring <robh+dt@kernel.org> wrote:
>     'r7' : 'renesas',
>     'r8' : 'renesas',
>     'r9' : 'renesas',
>     'emev2' : 'renesas',
>     'sh73a' : 'renesas',
>     'gr-' : 'renesas',
>     'iwg' : 'renesas',

Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Arnd Bergmann]

On Tue, May 2, 2023, at 21:40, Rob Herring wrote:
> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote:

> vendor_map = {
>     'alphascale' : 'alphascale',
>     'alpine' : 'alpine',

I would make this one 'amazon' if we go with current manufacturers.

>     'nspire' : 'nspire',

nspire is the name of the end-user product, so that doesn't quite
fit. The SoC was apparently an LSI logic Zevio, which is now owned
by Broadcom.

>     'mvebu' : 'marvell',
>     'mmp' : 'marvell',
>     'berlin' : 'berlin',

While berlin is related to pxa/mmp, this one is now owned
by Synaptics, and the 64-bit versions are already in the
synaptics subdir, so I'd go with teh same here.

>     'openbmc' : 'aspeed',
>     'en7' : 'airoha',

airoha is a separate company now, but the hardware is still
shared with mediatek, so we could consider lumping it into
that subdir, but a separate one may be better long-term.

>     'gemini' : 'gemini',

This one is also a product name, not a company. Apparently,
gemini was originally made by Storm Semiconductor, and then
by Cortina, which was subsequently acquired by Inphi, and that ended
up in Marvell after the product was already discontinued.

Out of the four, I'd probably go with 'cortina' as the
directory name.

>     'meson' : 'meson',

-> amlogic

>     'moxa' : 'moxa',
>     'mstar' : 'mstar',

-> sigmastar

>     'nuvo' : 'nuvoton',
>     'lpc' : 'lpc',

-> nxp

>     'lan96' : 'microchip',
>     'owl' : 'actions',
>     'ox8' : 'oxsemi',
>     'rda' : 'rda',

-> unisoc

>     'rtd' : 'realtek',
>     'r7' : 'renesas',
>     'r8' : 'renesas',
>     'r9' : 'renesas',
>     'emev2' : 'renesas',
>     'sh73a' : 'renesas',
>     'gr-' : 'renesas',
>     'iwg' : 'renesas',
>     'rk' : 'rockchip',
>     'rv11' : 'rockchip',
>     'rockchip' : 'rockchip',
>     'socfpga' : 'socfpga',

-> intel

>     'stm' : 'stm32',
>     'sti' : 'sti',
>     'st-pin' : 'sti',
>     'ste' : 'st-ericsson',
>     'spear' : 'spear',

I would put all five of these into 'st'. The ux500 was developed
in st-ericsson, but last sold by st, and the other ones are all
original st products.

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Rob Herring]

On Wed, May 3, 2023 at 6:02 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, May 2, 2023, at 21:40, Rob Herring wrote:
> > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> > vendor_map = {
> >     'alphascale' : 'alphascale',
> >     'alpine' : 'alpine',
>
> I would make this one 'amazon' if we go with current manufacturers.
>
> >     'nspire' : 'nspire',
>
> nspire is the name of the end-user product, so that doesn't quite
> fit. The SoC was apparently an LSI logic Zevio, which is now owned
> by Broadcom.

I'm inclined to leave it. I put it in the category of a one-off thing
that's not sharing anything

> >     'mvebu' : 'marvell',
> >     'mmp' : 'marvell',
> >     'berlin' : 'berlin',
>
> While berlin is related to pxa/mmp, this one is now owned
> by Synaptics, and the 64-bit versions are already in the
> synaptics subdir, so I'd go with teh same here.
>
> >     'openbmc' : 'aspeed',
> >     'en7' : 'airoha',
>
> airoha is a separate company now, but the hardware is still
> shared with mediatek, so we could consider lumping it into
> that subdir, but a separate one may be better long-term.
>
> >     'gemini' : 'gemini',
>
> This one is also a product name, not a company. Apparently,
> gemini was originally made by Storm Semiconductor, and then
> by Cortina, which was subsequently acquired by Inphi, and that ended
> up in Marvell after the product was already discontinued.
>
> Out of the four, I'd probably go with 'cortina' as the
> directory name.

I had 'cortina' previously. Linus wanted gemini...

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Linus Walleij]

On Wed, May 3, 2023 at 1:03 PM Arnd Bergmann <arnd@arndb.de> wrote:

> >     'gemini' : 'gemini',
>
> This one is also a product name, not a company. Apparently,
> gemini was originally made by Storm Semiconductor, and then
> by Cortina, which was subsequently acquired by Inphi, and that ended
> up in Marvell after the product was already discontinued.
>
> Out of the four, I'd probably go with 'cortina' as the
> directory name.
>

StorLink was the initial company, thus SL3516, SL3512
the name of the chips.

Then that company changed name to Storm Semiconductor.

Git acquired by Cortina.

Then Inphi acquired Cortina.

Then Marvell scooped up the IP.

If we *have* to use a company name I would use storlink,
because the chips are named after that.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Linux-stm32] [RFC PATCH 0/1] Categorize ARM dts directory

[Alexandre TORGUE]

On 5/3/23 13:02, Arnd Bergmann wrote:
> On Tue, May 2, 2023, at 21:40, Rob Herring wrote:
>> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote:
> 

...

> 
>>      'stm' : 'stm32',
>>      'sti' : 'sti',
>>      'st-pin' : 'sti',
>>      'ste' : 'st-ericsson',
>>      'spear' : 'spear',
> 
> I would put all five of these into 'st'. The ux500 was developed
> in st-ericsson, but last sold by st, and the other ones are all
> original st products.

Acked-by: Alexandre TORGUE <alexandre.torgue@st.com>

thanks
Alex

> 
>        Arnd
> _______________________________________________
> Linux-stm32 mailing list
> Linux-stm32@st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Jesper Nilsson]

On Tue, May 02, 2023 at 02:40:19PM -0500, Rob Herring wrote:
> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote:
> I've dusted off my script and made a branch[1] with the result.
> There's just a couple of fixes needed after the script is run (see the
> top commit). The cross arch includes are all fixed up by the script.
> dtbs_install maintains a flat install. I compared the number of .dtbs
> before and after to check the script.
> 
> I think the only issue remaining is finalizing the mapping of
> platforms to subdirs. What I have currently is a mixture of SoC
> families and vendors. The most notable are all the Freescale/NXP
> platforms, pxa, socfpga, and stm32. It's not consistent with arm64
> either. Once that's finalized, I still need to go update MAINTAINERS.
> 
> Here's the current mapping:
> 
> vendor_map = {
> [...]
>     'artpec' : 'axis',

Looks good for our platforms also, thanks!

/^JN - Jesper Nilsson
-- 
               Jesper Nilsson -- jesper.nilsson@axis.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Russell King (Oracle)]

On Tue, May 02, 2023 at 02:40:19PM -0500, Rob Herring wrote:
> I think the only issue remaining is finalizing the mapping of
> platforms to subdirs. What I have currently is a mixture of SoC
> families and vendors. The most notable are all the Freescale/NXP
> platforms, pxa, socfpga, and stm32. It's not consistent with arm64
> either. Once that's finalized, I still need to go update MAINTAINERS.

I haven't followed this discussion at all, so here's a question.

What does this mean for the _installed_ dtb files? Do they move
location? If they do, lots is going to break, because there will
be u-boot configurations and other scripts that assume the flat
directory structure for the installed dtb files.

I don't think changing the installed dtb structure is acceptable
at this point in time. It's something that _should_ have been
thought about when ARM was converted to dtb, it's too late to be
changing that now.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Arnd Bergmann]

On Thu, May 4, 2023, at 12:11, Russell King (Oracle) wrote:
> On Tue, May 02, 2023 at 02:40:19PM -0500, Rob Herring wrote:
>> I think the only issue remaining is finalizing the mapping of
>> platforms to subdirs. What I have currently is a mixture of SoC
>> families and vendors. The most notable are all the Freescale/NXP
>> platforms, pxa, socfpga, and stm32. It's not consistent with arm64
>> either. Once that's finalized, I still need to go update MAINTAINERS.
>
> I haven't followed this discussion at all, so here's a question.
>
> What does this mean for the _installed_ dtb files? Do they move
> location? If they do, lots is going to break, because there will
> be u-boot configurations and other scripts that assume the flat
> directory structure for the installed dtb files.
>
> I don't think changing the installed dtb structure is acceptable
> at this point in time. It's something that _should_ have been
> thought about when ARM was converted to dtb, it's too late to be
> changing that now.

Rob said earlier that his script does keep a flat directory
for the output of 'make dtbs_install'.

     Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Rob Herring]

On Tue, May 9, 2023 at 4:55 PM Jonathan Neuschäfer
<j.neuschaefer@gmx.net> wrote:
>
> On Tue, May 02, 2023 at 02:40:19PM -0500, Rob Herring wrote:
> [...]
> > I've dusted off my script and made a branch[1] with the result.
> > There's just a couple of fixes needed after the script is run (see the
> > top commit). The cross arch includes are all fixed up by the script.
> > dtbs_install maintains a flat install. I compared the number of .dtbs
> > before and after to check the script.
> >
> > I think the only issue remaining is finalizing the mapping of
> > platforms to subdirs. What I have currently is a mixture of SoC
> > families and vendors. The most notable are all the Freescale/NXP
> > platforms, pxa, socfpga, and stm32. It's not consistent with arm64
> > either. Once that's finalized, I still need to go update MAINTAINERS.
> >
> > Here's the current mapping:
> >
> > vendor_map = {
> [...]
> >     'aspeed' : 'aspeed',
> >     'ast2' : 'aspeed',
> >     'facebook' : 'aspeed',
> >     'ibm' : 'aspeed',
>
> >     'openbmc' : 'aspeed',
>
> The openbmc flash layouts are currently only used by aspeed devicetrees,
> but they don't really depend on any aspeed details. It would be possible
> to reuse them in Nuvoton BMC devicetrees in the future, for example.
>
> In that sense, I think putting them in a separate "openbmc" directory
> would be slightly better.

Could be used on arm64 or riscv too at some point. We do some cross
arch includes, but IMO it would be better to move to
include/dt-bindings/ or somewhere outside of arch/. Other common
things I didn't move. I could do that here too. I prefer to that the
sub-directories are just chip vendors/families.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 0/1] Categorize ARM dts directory

[Krzysztof Kozlowski]

On 25/04/2023 00:10, Rob Herring wrote:
>> I had some problem with gmail and sending mail too much users. I put Rob
>> and You and all the various list to try to workaround the "gmail spam
>> protection"
>>
>>> I am pretty sure we were discussing such split idea in the past and it
>>> did not get traction, but I cannot recall the exact discussion.
>>>
>>
>> I think the main issue here is how to handle bot and how problematic is
>> to merge this. As written in the cover letter the final version of this
>> should be a big series of 50+ patch with every commit specific to each
>> oem. In theory we should be able to merge the different oem separately
>> and try to at least start the categorization.
>> Another idea I got to at least have a "migration path" is to convert
>> every dts in the dts/ directory to a symbolic link that target the dts
>> in the correct oem. But I assume that would fix only part of the problem
>> and git am will still be problematic.
> 
> I have a script[1] that does the conversion written the last time this
> came up. Just have to agree on directory names. I think the easiest
> would be for Arnd/Olof to run it at the end of a merge window before
> rc1.
> 
> I'm very much in favor of this happening especially before *any*
> overlays are added to add to the mess (it's probably already
> happened).
> 
> Rob
> 
> [1] https://lore.kernel.org/all/20181204183649.GA5716@bogus/

This is the thread I was thinking about. Looks good for me (the original
script with exynos->samsung).

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel