LinuxLists.cc - [RFC PATCH 0/1] Categorize ARM dts directory

[permalink] [raw]

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

* Geert Uytterhoeven <[email protected]> [220329 09:02]:
> On Tue, Mar 29, 2022 at 10:03 AM Tony Lindgren <[email protected]> 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

2022-03-29 13:50:11

[permalink] [raw]

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

Hi Tony,

On Tue, Mar 29, 2022 at 10:03 AM Tony Lindgren <[email protected]> wrote:
> * Daniel Palmer <[email protected]> [220328 08:53]:
> > On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <[email protected]> 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 -- [email protected]

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

2022-03-29 16:48:36

by Krzysztof Kozlowski

[permalink] [raw]

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

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

2022-03-29 22:45:34

by Christian Marangi

[permalink] [raw]

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

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

2022-03-31 04:19:12

[permalink] [raw]

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

Hi,

* Daniel Palmer <[email protected]> [220328 08:53]:
> Hi Ansuel
>
> On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <[email protected]> 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

2023-04-24 22:18:46

[permalink] [raw]

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

On Tue, Mar 29, 2022 at 8:27 AM Ansuel Smith <[email protected]> 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/

2023-04-24 22:27:30

by Christian Marangi

[permalink] [raw]

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

Il giorno mar 25 apr 2023 alle ore 00:10 Rob Herring
<[email protected]> ha scritto:
>
> On Tue, Mar 29, 2022 at 8:27 AM Ansuel Smith <[email protected]> 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.

2023-04-25 07:31:52

[permalink] [raw]

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

Hi Rob,

On Tue, Apr 25, 2023 at 12:16 AM Rob Herring <[email protected]> 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 -- [email protected]

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

2023-04-25 08:01:46

by Krzysztof Kozlowski

[permalink] [raw]

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

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

2023-04-25 16:08:29

[permalink] [raw]

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

On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <[email protected]> wrote:
>
> Hi Rob,
>
> On Tue, Apr 25, 2023 at 12:16 AM Rob Herring <[email protected]> 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

2023-04-25 16:24:40

by Robin Murphy

[permalink] [raw]

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

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 <[email protected]> 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
>
>
>

2023-04-27 07:38:58

by Matthias Brugger

[permalink] [raw]

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

On 25/04/2023 00:23, Ansuel Smith wrote:
> Il giorno mar 25 apr 2023 alle ore 00:10 Rob Herring
> <[email protected]> ha scritto:
>>
>> On Tue, Mar 29, 2022 at 8:27 AM Ansuel Smith <[email protected]> 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

2023-04-27 07:39:31

by Matthias Brugger

[permalink] [raw]

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

On 25/04/2023 17:57, Rob Herring wrote:
> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <[email protected]> wrote:
>>
>> Hi Rob,
>>
>> On Tue, Apr 25, 2023 at 12:16 AM Rob Herring <[email protected]> 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

2023-04-27 07:48:18

[permalink] [raw]

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

On Thu, Apr 27, 2023 at 9:37 AM Matthias Brugger <[email protected]> wrote:
> On 25/04/2023 17:57, Rob Herring wrote:
> > On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <[email protected]> wrote:
> >> On Tue, Apr 25, 2023 at 12:16 AM Rob Herring <[email protected]> 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 -- [email protected]

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

2023-04-27 07:50:34

[permalink] [raw]

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

* Geert Uytterhoeven <[email protected]> [230427 07:47]:
> On Thu, Apr 27, 2023 at 9:37 AM Matthias Brugger <[email protected]> wrote:
> > On 25/04/2023 17:57, Rob Herring wrote:
> > > On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <[email protected]> wrote:
> > >> On Tue, Apr 25, 2023 at 12:16 AM Rob Herring <[email protected]> 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

2023-05-02 08:17:42

[permalink] [raw]

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

On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <[email protected]> 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

2023-05-02 19:06:25

[permalink] [raw]

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

On Tue, Apr 25, 2023 at 11:21 AM Robin Murphy <[email protected]> wrote:
>
> 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 <[email protected]> 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.

Indeed, this came up last time. Turns out I had already implemented
support to maintain the flat install. I just re-wrote it since
Makefile.dtbinst changed completely since then.

Rob

2023-05-02 19:50:45

[permalink] [raw]

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

On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <[email protected]> wrote:
>
> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
> > On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <[email protected]> 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

2023-05-02 20:07:03

by Krzysztof Kozlowski

[permalink] [raw]

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

On 02/05/2023 21:40, Rob Herring wrote:
> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <[email protected]> wrote:
>>
>> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
>>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <[email protected]> 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 <[email protected]>

> '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

2023-05-02 21:20:33

by Linus Walleij

[permalink] [raw]

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

On Tue, May 2, 2023 at 9:40 PM Rob Herring <[email protected]> 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 <[email protected]>

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

2023-05-02 21:40:14

[permalink] [raw]

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

On Tue, May 2, 2023 at 4:19 PM Linus Walleij <[email protected]> wrote:
>
> On Tue, May 2, 2023 at 9:40 PM Rob Herring <[email protected]> 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 <[email protected]>
>
> 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

2023-05-02 22:07:04

by Christian Hewitt

[permalink] [raw]

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

> On 2 May 2023, at 8:40 pm, Rob Herring <[email protected]> wrote:
>
> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <[email protected]> wrote:
>>
>> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
>>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <[email protected]> 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
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-amlogic

2023-05-02 22:58:54

by Dmitry Baryshkov

[permalink] [raw]

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

On 02/05/2023 22:40, Rob Herring wrote:
> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <[email protected]> wrote:
>>
>> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
>>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <[email protected]> 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

2023-05-02 23:13:09

by Florian Fainelli

[permalink] [raw]

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

On 5/2/23 12:40, Rob Herring wrote:
> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <[email protected]> wrote:
>>
>> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
>>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <[email protected]> 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

2023-05-03 01:05:49

[permalink] [raw]

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

On Tue, May 2, 2023 at 6:02 PM Florian Fainelli <[email protected]> wrote:
>
> On 5/2/23 12:40, Rob Herring wrote:
> > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <[email protected]> wrote:
> >>
> >> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
> >>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <[email protected]> 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

2023-05-03 01:20:40

by Shawn Guo

[permalink] [raw]

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

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 <[email protected]> wrote:
> >>
> >> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
> >>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <[email protected]> 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 <[email protected]>
>
> > '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
>

2023-05-03 01:20:41

[permalink] [raw]

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

On Tue, May 2, 2023 at 5:52 PM Dmitry Baryshkov
<[email protected]> wrote:
>
> On 02/05/2023 22:40, Rob Herring wrote:
> > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <[email protected]> wrote:
> >>
> >> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
> >>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <[email protected]> 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

2023-05-03 06:04:16

[permalink] [raw]

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

* Rob Herring <[email protected]> [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

2023-05-03 09:09:12

[permalink] [raw]

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

Hi Rob,

On Tue, May 2, 2023 at 9:40 PM Rob Herring <[email protected]> wrote:
> 'r7' : 'renesas',
> 'r8' : 'renesas',
> 'r9' : 'renesas',
> 'emev2' : 'renesas',
> 'sh73a' : 'renesas',
> 'gr-' : 'renesas',
> 'iwg' : 'renesas',

Acked-by: Geert Uytterhoeven <[email protected]>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

2023-05-03 10:50:06

[permalink] [raw]

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

On Wed, May 3, 2023, at 03:17, Rob Herring wrote:
> On Tue, May 2, 2023 at 5:52 PM Dmitry Baryshkov <[email protected]> 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

2023-05-03 11:02:10

by Neil Armstrong

[permalink] [raw]

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

On 03/05/2023 00:01, Christian Hewitt wrote:
>
>
>> On 2 May 2023, at 8:40 pm, Rob Herring <[email protected]> wrote:
>>
>> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <[email protected]> wrote:
>>>
>>> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
>>>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <[email protected]> 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
>> [email protected]
>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>

2023-05-03 11:02:37

[permalink] [raw]

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

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

2023-05-03 11:07:08

[permalink] [raw]

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

On Tue, May 2, 2023, at 21:40, Rob Herring wrote:
> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <[email protected]> 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

2023-05-03 12:10:57

by Jesper Nilsson

[permalink] [raw]

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

On Tue, May 02, 2023 at 02:40:19PM -0500, Rob Herring wrote:
> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <[email protected]> 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 -- [email protected]

2023-05-03 12:16:23

by Dmitry Baryshkov

[permalink] [raw]

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

On Wed, 3 May 2023 at 13:39, Arnd Bergmann <[email protected]> wrote:
>
> On Wed, May 3, 2023, at 03:17, Rob Herring wrote:
> > On Tue, May 2, 2023 at 5:52 PM Dmitry Baryshkov <[email protected]> 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

2023-05-03 12:19:41

[permalink] [raw]

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

On Wed, May 3, 2023, at 14:13, Dmitry Baryshkov wrote:
> On Wed, 3 May 2023 at 13:39, Arnd Bergmann <[email protected]> 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

2023-05-03 13:11:08

[permalink] [raw]

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

On Wed, May 3, 2023 at 6:02 AM Arnd Bergmann <[email protected]> wrote:
>
> On Tue, May 2, 2023, at 21:40, Rob Herring wrote:
> > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <[email protected]> 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

2023-05-03 13:20:53

[permalink] [raw]

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

On Wed, May 3, 2023 at 7:19 AM Arnd Bergmann <[email protected]> wrote:
>
> On Wed, May 3, 2023, at 14:13, Dmitry Baryshkov wrote:
> > On Wed, 3 May 2023 at 13:39, Arnd Bergmann <[email protected]> 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

2023-05-03 20:44:21

by Linus Walleij

[permalink] [raw]

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

On Wed, May 3, 2023 at 1:03 PM Arnd Bergmann <[email protected]> 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

2023-05-03 20:47:54

[permalink] [raw]

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

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

2023-05-03 20:50:10

by Linus Walleij

[permalink] [raw]

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

On Wed, May 3, 2023 at 10:37 PM Arnd Bergmann <[email protected]> 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

2023-05-03 22:27:57

[permalink] [raw]

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

On Wed, May 3, 2023 at 3:37 PM Arnd Bergmann <[email protected]> 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

2023-05-03 22:35:16

by Florian Fainelli

[permalink] [raw]

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

On 5/2/23 18:04, Rob Herring wrote:
> On Tue, May 2, 2023 at 6:02 PM Florian Fainelli <[email protected]> wrote:
>>
>> On 5/2/23 12:40, Rob Herring wrote:
>>> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <[email protected]> wrote:
>>>>
>>>> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote:
>>>>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <[email protected]> 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

2023-05-04 07:33:17

by Alexandre TORGUE

[permalink] [raw]

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

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 <[email protected]> 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 <[email protected]>

thanks
Alex

>
> Arnd
> _______________________________________________
> Linux-stm32 mailing list
> [email protected]
> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32

2023-05-04 10:13:47

by Russell King (Oracle)

[permalink] [raw]

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

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!

2023-05-04 11:52:06

[permalink] [raw]

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

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

2023-05-09 23:13:31

by Jonathan Neuschäfer

[permalink] [raw]

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

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.

Jonathan

[...]
> 'nuvo' : 'nuvoton',
[...]
> }
>
> Rob
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git arm-dts-move-v2

Attachments:

(No filename) (1.40 kB)
signature.asc (849.00 B)
Download all attachments

2023-06-08 20:50:57