Message ID | 20220328000915.15041-1-ansuelsmth@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Categorize ARM dts directory | expand |
Hi Ansuel On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <ansuelsmth@gmail.com> wrote: > > Hi, > as the title say, the intention of this ""series"" is to finally categorize > the ARM dts directory in subdirectory for each oem. While I agree with this change and think it's for the good (browsing the ARM dts directory at the moment is frustrating..) I think buildroot and others need to be told about this as it'll potentially break their kernel build scripting for ARM and probably messes up the configs they have for existing boards. > arch/arm/boot/dts/mstart/Makefile | 10 + > .../mstar-infinity-breadbee-common.dtsi | 0 > .../mstar-infinity-msc313-breadbee_crust.dts | 0 > .../{ => mstart}/mstar-infinity-msc313.dtsi | 0 > .../boot/dts/{ => mstart}/mstar-infinity.dtsi | 0 > .../mstar-infinity2m-ssd201-som2d01.dtsi | 0 > ...nfinity2m-ssd202d-100ask-dongshanpione.dts | 0 > .../mstar-infinity2m-ssd202d-miyoo-mini.dts | 0 > .../mstar-infinity2m-ssd202d-ssd201htv2.dts | 0 > .../mstar-infinity2m-ssd202d-unitv2.dts | 0 > ...sd202d-wirelesstag-ido-sbc2d06-v1b-22w.dts | 0 > ...ity2m-ssd202d-wirelesstag-ido-som2d01.dtsi | 0 > .../mstar-infinity2m-ssd202d.dtsi | 0 > .../mstar-infinity2m-ssd20xd.dtsi | 0 > .../dts/{ => mstart}/mstar-infinity2m.dtsi | 0 > .../mstar-infinity3-msc313e-breadbee.dts | 0 > .../{ => mstart}/mstar-infinity3-msc313e.dtsi | 0 > .../dts/{ => mstart}/mstar-infinity3.dtsi | 0 > .../mstar-mercury5-ssc8336n-midrived08.dts | 0 > .../{ => mstart}/mstar-mercury5-ssc8336n.dtsi | 0 > .../boot/dts/{ => mstart}/mstar-mercury5.dtsi | 0 > arch/arm/boot/dts/{ => mstart}/mstar-v7.dtsi | 0 s/mstart/mstar/ Cheers, Daniel
On Mon, Mar 28, 2022 at 02:09:14AM +0200, Ansuel Smith wrote: > Hi, > as the title say, the intention of this ""series"" is to finally categorize > the ARM dts directory in subdirectory for each oem. [...] > [1] https://gist.github.com/Ansuel/47c49925ee7ef4b1dd035afc74679ab5 > [2] https://gist.github.com/Ansuel/19f61f1e583c49407ce35c10e770fbe0 Nice idea, thank you! A few notes on categorization below. > create mode 100644 arch/arm/boot/dts/broadcom/Makefile > rename arch/arm/boot/dts/{ => broadcom}/bcm-cygnus-clock.dtsi (100%) Or maybe bcm instead of broadcom. Not sure which is preferred by Broadcom people. > create mode 100644 arch/arm/boot/dts/dove/Makefile > rename arch/arm/boot/dts/{ => dove}/dove-cm-a510.dtsi (100%) Arguably part of Marvell. > create mode 100644 arch/arm/boot/dts/edac/Makefile > rename arch/arm/boot/dts/{ => edac}/ecx-2000.dts (100%) > rename arch/arm/boot/dts/{ => edac}/ecx-common.dtsi (100%) > rename arch/arm/boot/dts/{ => edac}/highbank.dts (100%) Why edac? The most obvious name I can see here is calxeda. > create mode 100644 arch/arm/boot/dts/freescale/Makefile Freescale has been part of NXP for a while, so it might make sense to merge the freescale and nxp directories. I can't speak for NXP-the-company, so that's just my view as a bystander. > create mode 100644 arch/arm/boot/dts/kirkwood/Makefile The Kirkwood family should probably be sorted into Marvell. > create mode 100644 arch/arm/boot/dts/layerscape/Makefile > rename arch/arm/boot/dts/{ => layerscape}/ls1021a-moxa-uc-8410a.dts (100%) > rename arch/arm/boot/dts/{ => layerscape}/ls1021a-qds.dts (100%) > rename arch/arm/boot/dts/{ => layerscape}/ls1021a-tsn.dts (100%) > rename arch/arm/boot/dts/{ => layerscape}/ls1021a-twr.dts (100%) > rename arch/arm/boot/dts/{ => layerscape}/ls1021a.dtsi (100%) The Layerscape family is part of Freescale/NXP. > create mode 120000 arch/arm/boot/dts/nxp/armv7-m.dtsi armv7-m.dtsi is a bit confusing, because it contains a few devices at fixed addresses, so it looks vendor-specific at a first glance into the file. However, if it is actually as vendor-neutral as the name implies, I think it should live dts/ directly, rather than in vendor subdirectories. > rename arch/arm/boot/dts/{ => nxp}/lpc18xx.dtsi (100%) Here we have the NXP LPCxxxx family, which is AFAIK unrelated to the i.MX family (and thus the bulk of the Freescale legacy). > create mode 100644 arch/arm/boot/dts/vybrid/Makefile Vybrid is another chip family of NXP, with a good deal of Freescale legacy in it as evidenced by the "fsl," prefix in the devicetrees. Thanks, Jonathan
On Mon, Mar 28, 2022 at 03:21:08PM +0200, Jonathan Neuschäfer wrote: > On Mon, Mar 28, 2022 at 02:09:14AM +0200, Ansuel Smith wrote: > > Hi, > > as the title say, the intention of this ""series"" is to finally categorize > > the ARM dts directory in subdirectory for each oem. > [...] > > [1] https://gist.github.com/Ansuel/47c49925ee7ef4b1dd035afc74679ab5 > > [2] https://gist.github.com/Ansuel/19f61f1e583c49407ce35c10e770fbe0 > > Nice idea, thank you! > > A few notes on categorization below. > > > > create mode 100644 arch/arm/boot/dts/broadcom/Makefile > > rename arch/arm/boot/dts/{ => broadcom}/bcm-cygnus-clock.dtsi (100%) > > Or maybe bcm instead of broadcom. Not sure which is preferred by > Broadcom people. > In arm64 they used broadcom so i assume the full name looks correct. > > create mode 100644 arch/arm/boot/dts/dove/Makefile > > rename arch/arm/boot/dts/{ => dove}/dove-cm-a510.dtsi (100%) > > Arguably part of Marvell. > > > create mode 100644 arch/arm/boot/dts/edac/Makefile > > rename arch/arm/boot/dts/{ => edac}/ecx-2000.dts (100%) > > rename arch/arm/boot/dts/{ => edac}/ecx-common.dtsi (100%) > > rename arch/arm/boot/dts/{ => edac}/highbank.dts (100%) > > Why edac? > The most obvious name I can see here is calxeda. > > > create mode 100644 arch/arm/boot/dts/freescale/Makefile > > Freescale has been part of NXP for a while, so it might make sense to > merge the freescale and nxp directories. I can't speak for > NXP-the-company, so that's just my view as a bystander. > > > create mode 100644 arch/arm/boot/dts/kirkwood/Makefile > > The Kirkwood family should probably be sorted into Marvell. > > > create mode 100644 arch/arm/boot/dts/layerscape/Makefile > > rename arch/arm/boot/dts/{ => layerscape}/ls1021a-moxa-uc-8410a.dts (100%) > > rename arch/arm/boot/dts/{ => layerscape}/ls1021a-qds.dts (100%) > > rename arch/arm/boot/dts/{ => layerscape}/ls1021a-tsn.dts (100%) > > rename arch/arm/boot/dts/{ => layerscape}/ls1021a-twr.dts (100%) > > rename arch/arm/boot/dts/{ => layerscape}/ls1021a.dtsi (100%) > > The Layerscape family is part of Freescale/NXP. > > > create mode 120000 arch/arm/boot/dts/nxp/armv7-m.dtsi > > armv7-m.dtsi is a bit confusing, because it contains a few devices at > fixed addresses, so it looks vendor-specific at a first glance into the > file. However, if it is actually as vendor-neutral as the name implies, > I think it should live dts/ directly, rather than in vendor > subdirectories. > Considering it's really just 3 binding IMHO it should be just dropped and merged in other dtsi... But lets not extend this too much. This is really just a simplic link and armv7-m.dtsi is placed in dts/ I create links in each oem that includes it to skip any changes to the dts. > > rename arch/arm/boot/dts/{ => nxp}/lpc18xx.dtsi (100%) > > Here we have the NXP LPCxxxx family, which is AFAIK unrelated to the > i.MX family (and thus the bulk of the Freescale legacy). > > > create mode 100644 arch/arm/boot/dts/vybrid/Makefile > > Vybrid is another chip family of NXP, with a good deal of Freescale > legacy in it as evidenced by the "fsl," prefix in the devicetrees. > > > > Thanks, > Jonathan Thx for the hint hope to get more comments about the dubious categorization about nxp and freescale.
On Mon, Mar 28, 2022 at 03:27:13PM +0200, Ansuel Smith wrote: > On Mon, Mar 28, 2022 at 03:21:08PM +0200, Jonathan Neuschäfer wrote: > > On Mon, Mar 28, 2022 at 02:09:14AM +0200, Ansuel Smith wrote: > > > Hi, > > > as the title say, the intention of this ""series"" is to finally categorize > > > the ARM dts directory in subdirectory for each oem. > > [...] > > > [1] https://gist.github.com/Ansuel/47c49925ee7ef4b1dd035afc74679ab5 > > > [2] https://gist.github.com/Ansuel/19f61f1e583c49407ce35c10e770fbe0 > > > > Nice idea, thank you! > > > > A few notes on categorization below. > > > > > > > create mode 100644 arch/arm/boot/dts/broadcom/Makefile > > > rename arch/arm/boot/dts/{ => broadcom}/bcm-cygnus-clock.dtsi (100%) > > > > Or maybe bcm instead of broadcom. Not sure which is preferred by > > Broadcom people. > > > > In arm64 they used broadcom so i assume the full name looks correct. Alright. [...] > > > create mode 120000 arch/arm/boot/dts/nxp/armv7-m.dtsi > > > > armv7-m.dtsi is a bit confusing, because it contains a few devices at > > fixed addresses, so it looks vendor-specific at a first glance into the > > file. However, if it is actually as vendor-neutral as the name implies, > > I think it should live dts/ directly, rather than in vendor > > subdirectories. > > > > Considering it's really just 3 binding IMHO it should be just dropped > and merged in other dtsi... But lets not extend this too much. > This is really just a simplic link and armv7-m.dtsi is placed in dts/ > I create links in each oem that includes it to skip any changes to the > dts. Ah, I missed the link bit (hidden in the file permissions) :) I agree, this is something that can be cleaned up later. Jonathan
> Am 28.03.2022 um 15:21 schrieb Jonathan Neuschäfer <j.neuschaefer@gmx.net>: > > Or maybe bcm instead of broadcom. Not sure which is preferred by > Broadcom people. Maybe it should always follow the list of vendor prefixes as we are talking about DTS? just my 2cts, Nikolaus
Am Montag, 28. März 2022, 15:21:08 CEST schrieb Jonathan Neuschäfer: > * PGP Signed by an unknown key > > On Mon, Mar 28, 2022 at 02:09:14AM +0200, Ansuel Smith wrote: > > Hi, > > as the title say, the intention of this ""series"" is to finally > > categorize > > the ARM dts directory in subdirectory for each oem. > > [...] > > > [1] https://gist.github.com/Ansuel/47c49925ee7ef4b1dd035afc74679ab5 > > [2] https://gist.github.com/Ansuel/19f61f1e583c49407ce35c10e770fbe0 > > Nice idea, thank you! > > A few notes on categorization below. > [...] > > create mode 100644 arch/arm/boot/dts/freescale/Makefile > > Freescale has been part of NXP for a while, so it might make sense to > merge the freescale and nxp directories. I can't speak for > NXP-the-company, so that's just my view as a bystander. Please don't mix the names for arm and arm64. It's very confusing if the vendor directory is named differently for each architecture. >[...] > > create mode 120000 arch/arm/boot/dts/nxp/armv7-m.dtsi > > armv7-m.dtsi is a bit confusing, because it contains a few devices at > fixed addresses, so it looks vendor-specific at a first glance into the > file. However, if it is actually as vendor-neutral as the name implies, > I think it should live dts/ directly, rather than in vendor > subdirectories. This seems to be some generic devices common for all ARMv7M CPUs used in Cortex-M CPUs. It's also used by some stm32 .dtsi. Best regards, Alexander
On Tue, 29 Mar 2022, at 00:20, H. Nikolaus Schaller wrote: >> Am 28.03.2022 um 15:21 schrieb Jonathan Neuschäfer <j.neuschaefer@gmx.net>: >> >> Or maybe bcm instead of broadcom. Not sure which is preferred by >> Broadcom people. > > Maybe it should always follow the list of vendor prefixes as we are > talking about DTS? +1 (if we're actually going to do this). That would neuter most the mistakes and discussion and can be extracted from the dts files themselves. Andrew
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
Hi, * Daniel Palmer <daniel@0x0f.com> [220328 08:53]: > Hi Ansuel > > On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <ansuelsmth@gmail.com> wrote: > > > > Hi, > > as the title say, the intention of this ""series"" is to finally categorize > > the ARM dts directory in subdirectory for each oem. > > While I agree with this change and think it's for the good (browsing > the ARM dts directory at the moment is frustrating..) I think > buildroot and others need to be told about this as it'll potentially > break their kernel build scripting for ARM and probably messes up the > configs they have for existing boards. Yeah.. And ideally this would be done in smaller steps as these will conflict with all the other pending patches. For example, I have a pile of pending omap clock clean-up dts patches posted and tested waiting for v5.19-rc1 to apply. I'd rather not start redoing or fixing up the patches with sed :) What I'd like to have see is that at some point when suitable we move one machine at a time with a script if possible.. Maybe the dtb files generated would need to remain in the current directory until all of the machine dts files are moved? That should help with the build scripting too probably :) In general I like the idea though and I think we should do it. Regards, Tony
On Tue, 29 Mar 2022, at 18:23, Tony Lindgren wrote: > Hi, > > * Daniel Palmer <daniel@0x0f.com> [220328 08:53]: >> Hi Ansuel >> >> On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <ansuelsmth@gmail.com> wrote: >> > >> > Hi, >> > as the title say, the intention of this ""series"" is to finally categorize >> > the ARM dts directory in subdirectory for each oem. >> >> While I agree with this change and think it's for the good (browsing >> the ARM dts directory at the moment is frustrating..) I think >> buildroot and others need to be told about this as it'll potentially >> break their kernel build scripting for ARM and probably messes up the >> configs they have for existing boards. > > Yeah.. And ideally this would be done in smaller steps as these will > conflict with all the other pending patches. > > For example, I have a pile of pending omap clock clean-up dts patches > posted and tested waiting for v5.19-rc1 to apply. I'd rather not start > redoing or fixing up the patches with sed :) > > What I'd like to have see is that at some point when suitable we move > one machine at a time with a script if possible.. Maybe the dtb files > generated would need to remain in the current directory until all of > the machine dts files are moved? That should help with the build > scripting too probably :) There's probably some reason not to, but could we symlink the new paths in the subdirectories to the existing files to handle the transition? Then do the move to remove the symlinks at some future point. Andrew
Ansuel, All, On 28/03/2022 at 10:55, Daniel Palmer wrote: > Hi Ansuel > > On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <ansuelsmth@gmail.com> wrote: >> >> Hi, >> as the title say, the intention of this ""series"" is to finally categorize >> the ARM dts directory in subdirectory for each oem. > > While I agree with this change and think it's for the good (browsing > the ARM dts directory at the moment is frustrating..) I think > buildroot and others need to be told about this as it'll potentially > break their kernel build scripting for ARM and probably messes up the > configs they have for existing boards. This aspect mustn't be underestimated and I anticipate lots of issues during a long time on this particular topic of "build systems". Another aspect is CI and public or private testing farms we all have running. These aspects always refrained me to change anything in the naming scheme of our DT files, but if we go in this direction, we must really be prepared and I'm still not convince it's worth it... If this has to happen, I would also like to queue some file name changes to do all modifications in one go in order to lower the annoyance level of those who would need to adapt to those changes. BTW, is there a common scheme for dts/dtsi file naming? Is it more enforced in one way or another for arm64 in a sense that I can take some norm as an example? [..] Best regards, Nicolas
Hi Tony, On Tue, Mar 29, 2022 at 10:03 AM Tony Lindgren <tony@atomide.com> wrote: > * Daniel Palmer <daniel@0x0f.com> [220328 08:53]: > > On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <ansuelsmth@gmail.com> wrote: > > > as the title say, the intention of this ""series"" is to finally categorize > > > the ARM dts directory in subdirectory for each oem. > > > > While I agree with this change and think it's for the good (browsing > > the ARM dts directory at the moment is frustrating..) I think > > buildroot and others need to be told about this as it'll potentially > > break their kernel build scripting for ARM and probably messes up the > > configs they have for existing boards. > > Yeah.. And ideally this would be done in smaller steps as these will > conflict with all the other pending patches. > > For example, I have a pile of pending omap clock clean-up dts patches > posted and tested waiting for v5.19-rc1 to apply. I'd rather not start > redoing or fixing up the patches with sed :) Git merge/rebase/cherry-pick should handle renames fine? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi, On 28/03/2022 15:21:08+0200, Jonathan Neuschäfer wrote: > On Mon, Mar 28, 2022 at 02:09:14AM +0200, Ansuel Smith wrote: > > create mode 100644 arch/arm/boot/dts/freescale/Makefile > > Freescale has been part of NXP for a while, so it might make sense to > merge the freescale and nxp directories. I can't speak for > NXP-the-company, so that's just my view as a bystander. > Maybe we should wait for the market consolidation to end so we can put all the files in a single subfolder? this would save us from all the bikeshedding ;) > > create mode 100644 arch/arm/boot/dts/kirkwood/Makefile > > The Kirkwood family should probably be sorted into Marvell. > > > create mode 100644 arch/arm/boot/dts/layerscape/Makefile > > rename arch/arm/boot/dts/{ => layerscape}/ls1021a-moxa-uc-8410a.dts (100%) > > rename arch/arm/boot/dts/{ => layerscape}/ls1021a-qds.dts (100%) > > rename arch/arm/boot/dts/{ => layerscape}/ls1021a-tsn.dts (100%) > > rename arch/arm/boot/dts/{ => layerscape}/ls1021a-twr.dts (100%) > > rename arch/arm/boot/dts/{ => layerscape}/ls1021a.dtsi (100%) > > The Layerscape family is part of Freescale/NXP. > > > create mode 120000 arch/arm/boot/dts/nxp/armv7-m.dtsi > > armv7-m.dtsi is a bit confusing, because it contains a few devices at > fixed addresses, so it looks vendor-specific at a first glance into the > file. However, if it is actually as vendor-neutral as the name implies, > I think it should live dts/ directly, rather than in vendor > subdirectories. > > > rename arch/arm/boot/dts/{ => nxp}/lpc18xx.dtsi (100%) > > Here we have the NXP LPCxxxx family, which is AFAIK unrelated to the > i.MX family (and thus the bulk of the Freescale legacy). > > > create mode 100644 arch/arm/boot/dts/vybrid/Makefile > > Vybrid is another chip family of NXP, with a good deal of Freescale > legacy in it as evidenced by the "fsl," prefix in the devicetrees. > > > > Thanks, > Jonathan > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
* Geert Uytterhoeven <geert@linux-m68k.org> [220329 09:02]: > On Tue, Mar 29, 2022 at 10:03 AM Tony Lindgren <tony@atomide.com> wrote: > > For example, I have a pile of pending omap clock clean-up dts patches > > posted and tested waiting for v5.19-rc1 to apply. I'd rather not start > > redoing or fixing up the patches with sed :) > > Git merge/rebase/cherry-pick should handle renames fine? Possibly.. Not sure I'd count on that based on my earlier experiences though :) Tony
On 29/03/2022 11:54, Tony Lindgren wrote: > * Geert Uytterhoeven <geert@linux-m68k.org> [220329 09:02]: >> On Tue, Mar 29, 2022 at 10:03 AM Tony Lindgren <tony@atomide.com> wrote: >>> For example, I have a pile of pending omap clock clean-up dts patches >>> posted and tested waiting for v5.19-rc1 to apply. I'd rather not start >>> redoing or fixing up the patches with sed :) >> >> Git merge/rebase/cherry-pick should handle renames fine? > > Possibly.. Not sure I'd count on that based on my earlier experiences > though :) > Yes. If this could be split up in per silicon-vendor patches, the maintainer could take them. Although it might be a pain to soc maintainers to resolve small conflicts when merging that branches. Just my 5 cents. Matthias
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
On Tue, Mar 29, 2022 at 8:27 AM Ansuel Smith <ansuelsmth@gmail.com> wrote: > > On Tue, Mar 29, 2022 at 03:20:18PM +0200, Krzysztof Kozlowski wrote: > > On 28/03/2022 02:09, Ansuel Smith wrote: > > > Hi, > > > as the title say, the intention of this ""series"" is to finally categorize > > > the ARM dts directory in subdirectory for each oem. > > > > > > The main reason for this is that it became unpractical to handle 2600 > > > dts files and try to even understand/edit/check the situation for a > > > specific target. > > > > > > In arm64 we already have this kind of separation and I honestly think > > > that this was never proposed for ARM due to the fact that there are > > > 2600+ files to sort and the fact that it will be a mess to merge this > > > entirely but IMHO with a little bit of effort we can finally solve this > > > problem and have a well organized directory just like arm64. > > > > > > Some prerequisite on how this work was done: > > > - This comes entirely from a python script created by me for the task. > > > linked here [1] > > > - I had to manually categorize all the different arch in the makefile > > > based on the oem. I searched every arch on the internet trying to > > > understand the correct oem. I hope they are correct but I would love > > > some comments about them. > > > - This current ""series"" is all squashed in one big commit to better > > > receive comments for this. The final version ideally would have all > > > changes in separate commits. The script can already do this, it's just > > > commented. > > > > > > Here is a list of some discoveries while doing all the sorting. > > > These are totally additional reason why we need this. > > > > > > While creating the script I discovered some funny things: > > > - We have orphan dts! There are dts that are never compiled and are > > > there just for reference. We would never have noticed this without this > > > change and probably nobody noticed it. They are currently all listed > > > in the python script. > > > - We have dtsi shared across different oem. My current solution for them > > > is: NOT SORT THEM and leave them in the generic directory and create a > > > link in each oem dts that points to these dtsi. This is to try in > > > every way possible to skip any additional changes to the dts. > > > Current dtsi that suffers from this are only 3. (listed in the script) > > > - arm64 dts and dtsi reference ARM dts. Obviously this change would cause > > > broken include for these special dtsi. The script creates a dependency > > > table of the entire arm64 directory and fix every broken dependency > > > (hoping they all use a sane include logic... regex is used to parse > > > all the different dependency) > > > > > > So in short the script does the following steps: > > > 1. Enumerate all the action to do... (dts to move, scan dependency for > > > the dts...) > > > 2. Generate the arm64 dependency > > > 3. Creates the Makefile > > > 4. Generate the Makefiles for the current oem > > > 5. Move all the related dts and dtsi for the current oem > > > 6. Check broken dependency and fix them by editing the dts and writing > > > the correct include (or fix any symbolic link) > > > > > > This is an output that describes all the things done by the script [2] > > > > > > I really hope I didn't commit any logic mistake in the script but most > > > of the work should be done. > > > > > > > +Cc Arnd and Olof, > > > > Ansuel, > > Thanks for you patch. Please cc the SoC maintainers in such submissions. > > It seems that you got some quite nice discussion, but still the core > > folks are not Cced, so no one would be able to take your patch... > > > > I had some problem with gmail and sending mail too much users. I put Rob > and You and all the various list to try to workaround the "gmail spam > protection" > > > I am pretty sure we were discussing such split idea in the past and it > > did not get traction, but I cannot recall the exact discussion. > > > > I think the main issue here is how to handle bot and how problematic is > to merge this. As written in the cover letter the final version of this > should be a big series of 50+ patch with every commit specific to each > oem. In theory we should be able to merge the different oem separately > and try to at least start the categorization. > Another idea I got to at least have a "migration path" is to convert > every dts in the dts/ directory to a symbolic link that target the dts > in the correct oem. But I assume that would fix only part of the problem > and git am will still be problematic. I have a script[1] that does the conversion written the last time this came up. Just have to agree on directory names. I think the easiest would be for Arnd/Olof to run it at the end of a merge window before rc1. I'm very much in favor of this happening especially before *any* overlays are added to add to the mess (it's probably already happened). Rob [1] https://lore.kernel.org/all/20181204183649.GA5716@bogus/
Il giorno mar 25 apr 2023 alle ore 00:10 Rob Herring <robh+dt@kernel.org> ha scritto: > > On Tue, Mar 29, 2022 at 8:27 AM Ansuel Smith <ansuelsmth@gmail.com> wrote: > > > > On Tue, Mar 29, 2022 at 03:20:18PM +0200, Krzysztof Kozlowski wrote: > > > On 28/03/2022 02:09, Ansuel Smith wrote: > > > > Hi, > > > > as the title say, the intention of this ""series"" is to finally categorize > > > > the ARM dts directory in subdirectory for each oem. > > > > > > > > The main reason for this is that it became unpractical to handle 2600 > > > > dts files and try to even understand/edit/check the situation for a > > > > specific target. > > > > > > > > In arm64 we already have this kind of separation and I honestly think > > > > that this was never proposed for ARM due to the fact that there are > > > > 2600+ files to sort and the fact that it will be a mess to merge this > > > > entirely but IMHO with a little bit of effort we can finally solve this > > > > problem and have a well organized directory just like arm64. > > > > > > > > Some prerequisite on how this work was done: > > > > - This comes entirely from a python script created by me for the task. > > > > linked here [1] > > > > - I had to manually categorize all the different arch in the makefile > > > > based on the oem. I searched every arch on the internet trying to > > > > understand the correct oem. I hope they are correct but I would love > > > > some comments about them. > > > > - This current ""series"" is all squashed in one big commit to better > > > > receive comments for this. The final version ideally would have all > > > > changes in separate commits. The script can already do this, it's just > > > > commented. > > > > > > > > Here is a list of some discoveries while doing all the sorting. > > > > These are totally additional reason why we need this. > > > > > > > > While creating the script I discovered some funny things: > > > > - We have orphan dts! There are dts that are never compiled and are > > > > there just for reference. We would never have noticed this without this > > > > change and probably nobody noticed it. They are currently all listed > > > > in the python script. > > > > - We have dtsi shared across different oem. My current solution for them > > > > is: NOT SORT THEM and leave them in the generic directory and create a > > > > link in each oem dts that points to these dtsi. This is to try in > > > > every way possible to skip any additional changes to the dts. > > > > Current dtsi that suffers from this are only 3. (listed in the script) > > > > - arm64 dts and dtsi reference ARM dts. Obviously this change would cause > > > > broken include for these special dtsi. The script creates a dependency > > > > table of the entire arm64 directory and fix every broken dependency > > > > (hoping they all use a sane include logic... regex is used to parse > > > > all the different dependency) > > > > > > > > So in short the script does the following steps: > > > > 1. Enumerate all the action to do... (dts to move, scan dependency for > > > > the dts...) > > > > 2. Generate the arm64 dependency > > > > 3. Creates the Makefile > > > > 4. Generate the Makefiles for the current oem > > > > 5. Move all the related dts and dtsi for the current oem > > > > 6. Check broken dependency and fix them by editing the dts and writing > > > > the correct include (or fix any symbolic link) > > > > > > > > This is an output that describes all the things done by the script [2] > > > > > > > > I really hope I didn't commit any logic mistake in the script but most > > > > of the work should be done. > > > > > > > > > > +Cc Arnd and Olof, > > > > > > Ansuel, > > > Thanks for you patch. Please cc the SoC maintainers in such submissions. > > > It seems that you got some quite nice discussion, but still the core > > > folks are not Cced, so no one would be able to take your patch... > > > > > > > I had some problem with gmail and sending mail too much users. I put Rob > > and You and all the various list to try to workaround the "gmail spam > > protection" > > > > > I am pretty sure we were discussing such split idea in the past and it > > > did not get traction, but I cannot recall the exact discussion. > > > > > > > I think the main issue here is how to handle bot and how problematic is > > to merge this. As written in the cover letter the final version of this > > should be a big series of 50+ patch with every commit specific to each > > oem. In theory we should be able to merge the different oem separately > > and try to at least start the categorization. > > Another idea I got to at least have a "migration path" is to convert > > every dts in the dts/ directory to a symbolic link that target the dts > > in the correct oem. But I assume that would fix only part of the problem > > and git am will still be problematic. > > I have a script[1] that does the conversion written the last time this > came up. Just have to agree on directory names. I think the easiest > would be for Arnd/Olof to run it at the end of a merge window before > rc1. > > I'm very much in favor of this happening especially before *any* > overlays are added to add to the mess (it's probably already > happened). > > Rob > > [1] https://lore.kernel.org/all/20181204183649.GA5716@bogus/ Hi Rob, thanks for recovering this. I remember also providing a script. Anyway considering the amount of stuff to move, I feel like some OEM might be problematic to move due to rebase and merging problems. We should consider accepting moving only some and keep other in the unsorted path. And move them at the first time possible with the help of the maintainers. One main blocker of this is some qcom dts that are linked to arm64 directory, so for some dts special care is needed.
Hi Rob, On Tue, Apr 25, 2023 at 12:16 AM Rob Herring <robh+dt@kernel.org> wrote: > I have a script[1] that does the conversion written the last time this > came up. Just have to agree on directory names. I think the easiest > would be for Arnd/Olof to run it at the end of a merge window before > rc1. "emev2" and "sh7" are missing for renesas. Does your script also cater for .dts files not matching any pattern, but including a .dtsi file that does match a pattern? > I'm very much in favor of this happening especially before *any* > overlays are added to add to the mess (it's probably already > happened). ;-) > [1] https://lore.kernel.org/all/20181204183649.GA5716@bogus/ Thanks! Gr{oetje,eeting}s, Geert
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
On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Rob, > > On Tue, Apr 25, 2023 at 12:16 AM Rob Herring <robh+dt@kernel.org> wrote: > > I have a script[1] that does the conversion written the last time this > > came up. Just have to agree on directory names. I think the easiest > > would be for Arnd/Olof to run it at the end of a merge window before > > rc1. > > "emev2" and "sh7" are missing for renesas. No doubt it's been bitrotting (or I may have missed some). > Does your script also cater for .dts files not matching any pattern, > but including a .dtsi file that does match a pattern? I assume I built everything after moving, but maybe not... That's all just "details". First, we need agreement on a) moving things to subdirs and b) doing it 1-by-1 or all at once. So far we've been stuck on a) for being 'too much churn'. One nice thing with subdirs is 'make CHECK_DTBS=y arch/arm/boot/dts/foo/' can build everything for a platform family without having to mess with the kconfig. Maybe most folks don't care, but I do. My CI job running schema checks looks like this to deal with grouping the arm dts files (this list is probably out of date too, but less so): if [ "$ARCH" = "arm" ]; then VENDOR_LIST="alphascale alpine artpec aspeed axm bcm cx9 (ecx|highbank) \ efm ep7 imx1 imx23 imx28 imx27 imx5 imx6 imx7 ls vf qcom \ (am3|am4|am5|dra|keystone|omap|compulab|logicpd|elpida|motorola-cpcap|da|dm) \ nspire armada dove kirkwood orion mvebu mmp2 berlin pxa (arm-|integ|mps|ve) \ (at91|sama|usb_|tny_|mpa1600|animeo_ip|aks-cdu|ethernut5|evk-pro3|pm9g45|ge86) \ exynos s3c s5p gemini (hisi|hi3|hip) mt meson moxa nuvo lpc owl ox8 \ (r7|r8|r9|emev2|sh73a|gr-|iwg) (rk|rv11) socfpga stm (sti|st-pin) ste \ spear (sun|axp) tegra uniph (vt8500|wm8) xen zynq" else VENDOR_LIST=$(ls arch/$ARCH/boot/dts/ | xargs) fi Rob
On 29/03/2022 9:50 am, Nicolas Ferre wrote: > Ansuel, All, > > On 28/03/2022 at 10:55, Daniel Palmer wrote: >> Hi Ansuel >> >> On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <ansuelsmth@gmail.com> wrote: >>> >>> Hi, >>> as the title say, the intention of this ""series"" is to finally >>> categorize >>> the ARM dts directory in subdirectory for each oem. >> >> While I agree with this change and think it's for the good (browsing >> the ARM dts directory at the moment is frustrating..) I think >> buildroot and others need to be told about this as it'll potentially >> break their kernel build scripting for ARM and probably messes up the >> configs they have for existing boards. > > This aspect mustn't be underestimated and I anticipate lots of issues > during a long time on this particular topic of "build systems". > > Another aspect is CI and public or private testing farms we all have > running. Yet another is if this affects what `make dtbs_install` does (I don't know for sure, but I'd be inclined to suspect it might). Some distros use that to deliver the DTBs as part of their kernel package, so if paths suddenly change it could break end users' bootloader setups too. Thanks, Robin. > These aspects always refrained me to change anything in the naming > scheme of our DT files, but if we go in this direction, we must really > be prepared and I'm still not convince it's worth it... > > > If this has to happen, I would also like to queue some file name changes > to do all modifications in one go in order to lower the annoyance level > of those who would need to adapt to those changes. > > BTW, is there a common scheme for dts/dtsi file naming? Is it more > enforced in one way or another for arm64 in a sense that I can take some > norm as an example? > > [..] > > Best regards, > Nicolas > > >
On 25/04/2023 00:23, Ansuel Smith wrote: > Il giorno mar 25 apr 2023 alle ore 00:10 Rob Herring > <robh+dt@kernel.org> ha scritto: >> >> On Tue, Mar 29, 2022 at 8:27 AM Ansuel Smith <ansuelsmth@gmail.com> wrote: >>> >>> On Tue, Mar 29, 2022 at 03:20:18PM +0200, Krzysztof Kozlowski wrote: >>>> On 28/03/2022 02:09, Ansuel Smith wrote: >>>>> Hi, >>>>> as the title say, the intention of this ""series"" is to finally categorize >>>>> the ARM dts directory in subdirectory for each oem. >>>>> >>>>> The main reason for this is that it became unpractical to handle 2600 >>>>> dts files and try to even understand/edit/check the situation for a >>>>> specific target. >>>>> >>>>> In arm64 we already have this kind of separation and I honestly think >>>>> that this was never proposed for ARM due to the fact that there are >>>>> 2600+ files to sort and the fact that it will be a mess to merge this >>>>> entirely but IMHO with a little bit of effort we can finally solve this >>>>> problem and have a well organized directory just like arm64. >>>>> >>>>> Some prerequisite on how this work was done: >>>>> - This comes entirely from a python script created by me for the task. >>>>> linked here [1] >>>>> - I had to manually categorize all the different arch in the makefile >>>>> based on the oem. I searched every arch on the internet trying to >>>>> understand the correct oem. I hope they are correct but I would love >>>>> some comments about them. >>>>> - This current ""series"" is all squashed in one big commit to better >>>>> receive comments for this. The final version ideally would have all >>>>> changes in separate commits. The script can already do this, it's just >>>>> commented. >>>>> >>>>> Here is a list of some discoveries while doing all the sorting. >>>>> These are totally additional reason why we need this. >>>>> >>>>> While creating the script I discovered some funny things: >>>>> - We have orphan dts! There are dts that are never compiled and are >>>>> there just for reference. We would never have noticed this without this >>>>> change and probably nobody noticed it. They are currently all listed >>>>> in the python script. >>>>> - We have dtsi shared across different oem. My current solution for them >>>>> is: NOT SORT THEM and leave them in the generic directory and create a >>>>> link in each oem dts that points to these dtsi. This is to try in >>>>> every way possible to skip any additional changes to the dts. >>>>> Current dtsi that suffers from this are only 3. (listed in the script) >>>>> - arm64 dts and dtsi reference ARM dts. Obviously this change would cause >>>>> broken include for these special dtsi. The script creates a dependency >>>>> table of the entire arm64 directory and fix every broken dependency >>>>> (hoping they all use a sane include logic... regex is used to parse >>>>> all the different dependency) >>>>> >>>>> So in short the script does the following steps: >>>>> 1. Enumerate all the action to do... (dts to move, scan dependency for >>>>> the dts...) >>>>> 2. Generate the arm64 dependency >>>>> 3. Creates the Makefile >>>>> 4. Generate the Makefiles for the current oem >>>>> 5. Move all the related dts and dtsi for the current oem >>>>> 6. Check broken dependency and fix them by editing the dts and writing >>>>> the correct include (or fix any symbolic link) >>>>> >>>>> This is an output that describes all the things done by the script [2] >>>>> >>>>> I really hope I didn't commit any logic mistake in the script but most >>>>> of the work should be done. >>>>> >>>> >>>> +Cc Arnd and Olof, >>>> >>>> Ansuel, >>>> Thanks for you patch. Please cc the SoC maintainers in such submissions. >>>> It seems that you got some quite nice discussion, but still the core >>>> folks are not Cced, so no one would be able to take your patch... >>>> >>> >>> I had some problem with gmail and sending mail too much users. I put Rob >>> and You and all the various list to try to workaround the "gmail spam >>> protection" >>> >>>> I am pretty sure we were discussing such split idea in the past and it >>>> did not get traction, but I cannot recall the exact discussion. >>>> >>> >>> I think the main issue here is how to handle bot and how problematic is >>> to merge this. As written in the cover letter the final version of this >>> should be a big series of 50+ patch with every commit specific to each >>> oem. In theory we should be able to merge the different oem separately >>> and try to at least start the categorization. >>> Another idea I got to at least have a "migration path" is to convert >>> every dts in the dts/ directory to a symbolic link that target the dts >>> in the correct oem. But I assume that would fix only part of the problem >>> and git am will still be problematic. >> >> I have a script[1] that does the conversion written the last time this >> came up. Just have to agree on directory names. I think the easiest >> would be for Arnd/Olof to run it at the end of a merge window before >> rc1. >> >> I'm very much in favor of this happening especially before *any* >> overlays are added to add to the mess (it's probably already >> happened). >> >> Rob >> >> [1] https://lore.kernel.org/all/20181204183649.GA5716@bogus/ > > Hi Rob, > thanks for recovering this. I remember also providing a script. > > Anyway considering the amount of stuff to move, I feel like some > OEM might be problematic to move due to rebase and merging problems. > > We should consider accepting moving only some and keep other > in the unsorted path. And move them at the first time possible with > the help of the maintainers. > > One main blocker of this is some qcom dts that are linked to arm64 > directory, so for some dts special care is needed. > Same happens for broadcom RaspberryPi DTS. The arm64 ones include the arm ones. Regards, Matthias
On 25/04/2023 17:57, Rob Herring wrote: > On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: >> >> Hi Rob, >> >> On Tue, Apr 25, 2023 at 12:16 AM Rob Herring <robh+dt@kernel.org> wrote: >>> I have a script[1] that does the conversion written the last time this >>> came up. Just have to agree on directory names. I think the easiest >>> would be for Arnd/Olof to run it at the end of a merge window before >>> rc1. >> >> "emev2" and "sh7" are missing for renesas. > > No doubt it's been bitrotting (or I may have missed some). > >> Does your script also cater for .dts files not matching any pattern, >> but including a .dtsi file that does match a pattern? > > I assume I built everything after moving, but maybe not... > > That's all just "details". First, we need agreement on a) moving > things to subdirs and b) doing it 1-by-1 or all at once. So far we've > been stuck on a) for being 'too much churn'. > I think it makes sense to move them and probably the best way to do so is, as you proposed: that Arnd or Olof run the script to move them just before -rc1 Regards, Matthias > One nice thing with subdirs is 'make CHECK_DTBS=y > arch/arm/boot/dts/foo/' can build everything for a platform family > without having to mess with the kconfig. Maybe most folks don't care, > but I do. My CI job running schema checks looks like this to deal with > grouping the arm dts files (this list is probably out of date too, but > less so): > > if [ "$ARCH" = "arm" ]; then > VENDOR_LIST="alphascale alpine artpec aspeed axm bcm cx9 > (ecx|highbank) \ > efm ep7 imx1 imx23 imx28 imx27 imx5 imx6 imx7 ls vf qcom \ > (am3|am4|am5|dra|keystone|omap|compulab|logicpd|elpida|motorola-cpcap|da|dm) > \ > nspire armada dove kirkwood orion mvebu mmp2 berlin pxa > (arm-|integ|mps|ve) \ > (at91|sama|usb_|tny_|mpa1600|animeo_ip|aks-cdu|ethernut5|evk-pro3|pm9g45|ge86) > \ > exynos s3c s5p gemini (hisi|hi3|hip) mt meson moxa nuvo > lpc owl ox8 \ > (r7|r8|r9|emev2|sh73a|gr-|iwg) (rk|rv11) socfpga stm > (sti|st-pin) ste \ > spear (sun|axp) tegra uniph (vt8500|wm8) xen zynq" > else > VENDOR_LIST=$(ls arch/$ARCH/boot/dts/ | xargs) > fi > > Rob
On Thu, Apr 27, 2023 at 9:37 AM Matthias Brugger <matthias.bgg@gmail.com> wrote: > On 25/04/2023 17:57, Rob Herring wrote: > > On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > >> On Tue, Apr 25, 2023 at 12:16 AM Rob Herring <robh+dt@kernel.org> wrote: > >>> I have a script[1] that does the conversion written the last time this > >>> came up. Just have to agree on directory names. I think the easiest > >>> would be for Arnd/Olof to run it at the end of a merge window before > >>> rc1. > >> > >> "emev2" and "sh7" are missing for renesas. > > > > No doubt it's been bitrotting (or I may have missed some). > > > >> Does your script also cater for .dts files not matching any pattern, > >> but including a .dtsi file that does match a pattern? > > > > I assume I built everything after moving, but maybe not... > > > > That's all just "details". First, we need agreement on a) moving > > things to subdirs and b) doing it 1-by-1 or all at once. So far we've > > been stuck on a) for being 'too much churn'. > > > > I think it makes sense to move them and probably the best way to do so is, as > you proposed: that Arnd or Olof run the script to move them just before -rc1 FTR, no objections from my side. Gr{oetje,eeting}s, Geert
* Geert Uytterhoeven <geert@linux-m68k.org> [230427 07:47]: > On Thu, Apr 27, 2023 at 9:37 AM Matthias Brugger <matthias.bgg@gmail.com> wrote: > > On 25/04/2023 17:57, Rob Herring wrote: > > > On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > >> On Tue, Apr 25, 2023 at 12:16 AM Rob Herring <robh+dt@kernel.org> wrote: > > >>> I have a script[1] that does the conversion written the last time this > > >>> came up. Just have to agree on directory names. I think the easiest > > >>> would be for Arnd/Olof to run it at the end of a merge window before > > >>> rc1. > > >> > > >> "emev2" and "sh7" are missing for renesas. > > > > > > No doubt it's been bitrotting (or I may have missed some). > > > > > >> Does your script also cater for .dts files not matching any pattern, > > >> but including a .dtsi file that does match a pattern? > > > > > > I assume I built everything after moving, but maybe not... > > > > > > That's all just "details". First, we need agreement on a) moving > > > things to subdirs and b) doing it 1-by-1 or all at once. So far we've > > > been stuck on a) for being 'too much churn'. > > > > > > > I think it makes sense to move them and probably the best way to do so is, as > > you proposed: that Arnd or Olof run the script to move them just before -rc1 > > FTR, no objections from my side. Sounds good to me. Regards, Tony
On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote: > On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > >> Does your script also cater for .dts files not matching any pattern, >> but including a .dtsi file that does match a pattern? > > I assume I built everything after moving, but maybe not... > > That's all just "details". First, we need agreement on a) moving > things to subdirs and b) doing it 1-by-1 or all at once. So far we've > been stuck on a) for being 'too much churn'. Sorry for missing most of the discussion last week. The script sounds fine to me, the only reason I didn't want to do this in the past is that we had the plan to move platforms out of the kernel tree to an external repository and I wanted to do this platform at a time and also only move each one once. I don't think that is going to happen anytime soon now, so let's just do your script. Can you send me the script and/or a pull request of the resulting tree based on my soc/dt branch? Everything is merged upstream, and I think git-merge would handle the remaining merges with any other changes in mainline. Arnd
On Tue, Apr 25, 2023 at 11:21 AM Robin Murphy <robin.murphy@arm.com> 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 <ansuelsmth@gmail.com> wrote: > >>> > >>> Hi, > >>> as the title say, the intention of this ""series"" is to finally > >>> categorize > >>> the ARM dts directory in subdirectory for each oem. > >> > >> While I agree with this change and think it's for the good (browsing > >> the ARM dts directory at the moment is frustrating..) I think > >> buildroot and others need to be told about this as it'll potentially > >> break their kernel build scripting for ARM and probably messes up the > >> configs they have for existing boards. > > > > This aspect mustn't be underestimated and I anticipate lots of issues > > during a long time on this particular topic of "build systems". > > > > Another aspect is CI and public or private testing farms we all have > > running. > > Yet another is if this affects what `make dtbs_install` does (I don't > know for sure, but I'd be inclined to suspect it might). Some distros > use that to deliver the DTBs as part of their kernel package, so if > paths suddenly change it could break end users' bootloader setups too. 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
On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote: > > On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote: > > On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > >> Does your script also cater for .dts files not matching any pattern, > >> but including a .dtsi file that does match a pattern? > > > > I assume I built everything after moving, but maybe not... > > > > That's all just "details". First, we need agreement on a) moving > > things to subdirs and b) doing it 1-by-1 or all at once. So far we've > > been stuck on a) for being 'too much churn'. > > Sorry for missing most of the discussion last week. The script sounds > fine to me, the only reason I didn't want to do this in the past is that > we had the plan to move platforms out of the kernel tree to an external > repository and I wanted to do this platform at a time and also only move > each one once. I don't think that is going to happen anytime soon now, > so let's just do your script. > > Can you send me the script and/or a pull request of the resulting > tree based on my soc/dt branch? Everything is merged upstream, > and I think git-merge would handle the remaining merges with any > other changes in mainline. I've dusted off my script and made a branch[1] with the result. There's just a couple of fixes needed after the script is run (see the top commit). The cross arch includes are all fixed up by the script. dtbs_install maintains a flat install. I compared the number of .dtbs before and after to check the script. I think the only issue remaining is finalizing the mapping of platforms to subdirs. What I have currently is a mixture of SoC families and vendors. The most notable are all the Freescale/NXP platforms, pxa, socfpga, and stm32. It's not consistent with arm64 either. Once that's finalized, I still need to go update MAINTAINERS. Here's the current mapping: vendor_map = { 'alphascale' : 'alphascale', 'alpine' : 'alpine', 'artpec' : 'axis', 'axm' : 'lsi', 'cx9' : 'cnxt', 'ecx' : 'calxeda', 'highbank' : 'calxeda', 'ep7' : 'cirrus', 'mxs': 'mxs', 'imx23': 'mxs', 'imx28': 'mxs', 'sun' : 'allwinner', 'imx': 'imx', 'e6' : 'imx', 'e7' : 'imx', 'mba6' : 'imx', 'ls': 'fsl', 'vf': 'fsl', 'qcom': 'qcom', 'am3' : 'ti', 'am4' : 'ti', 'am5' : 'ti', 'dra' : 'ti', 'keystone' : 'ti', 'omap' : 'ti', 'compulab' : 'ti', 'logicpd' : 'ti', 'elpida' : 'ti', 'motorola' : 'ti', 'twl' : 'ti', 'da' : 'ti', 'dm' : 'ti', 'nspire' : 'nspire', 'armada' : 'marvell', 'dove' : 'marvell', 'kirkwood' : 'marvell', 'orion' : 'marvell', 'mvebu' : 'marvell', 'mmp' : 'marvell', 'berlin' : 'berlin', 'pxa2' : 'pxa', 'pxa3' : 'pxa', 'pxa' : 'marvell', 'arm-' : 'arm', 'integ' : 'arm', 'mps' : 'arm', 've' : 'arm', 'aspeed' : 'aspeed', 'ast2' : 'aspeed', 'facebook' : 'aspeed', 'ibm' : 'aspeed', 'openbmc' : 'aspeed', 'en7' : 'airoha', 'at91' : 'microchip', 'sama' : 'microchip', 'sam9' : 'microchip', 'usb_' : 'microchip', 'tny_' : 'microchip', 'mpa1600' : 'microchip', 'animeo_ip' : 'microchip', 'aks-cdu' : 'microchip', 'ethernut5' : 'microchip', 'evk-pro3' : 'microchip', 'pm9g45' : 'microchip', 'ge86' : 'microchip', 'bcm' : 'brcm', 'exynos' : 'samsung', 's3c' : 'samsung', 's5p' : 'samsung', 'gemini' : 'gemini', 'hi3' : 'hisilicon', 'hip' : 'hisilicon', 'hisi' : 'hisilicon', 'sd5' : 'hisilicon', 'hpe' : 'hpe', 'intel': 'intel', 'mt' : 'mediatek', 'meson' : 'meson', 'moxa' : 'moxa', 'mstar' : 'mstar', 'nuvo' : 'nuvoton', 'lpc' : 'lpc', 'lan96' : 'microchip', 'owl' : 'actions', 'ox8' : 'oxsemi', 'rda' : 'rda', 'rtd' : 'realtek', 'r7' : 'renesas', 'r8' : 'renesas', 'r9' : 'renesas', 'emev2' : 'renesas', 'sh73a' : 'renesas', 'gr-' : 'renesas', 'iwg' : 'renesas', 'rk' : 'rockchip', 'rv11' : 'rockchip', 'rockchip' : 'rockchip', 'socfpga' : 'socfpga', 'stm' : 'stm32', 'sti' : 'sti', 'st-pin' : 'sti', 'ste' : 'st-ericsson', 'spear' : 'spear', 'axp' : 'allwinner', 'tegra' : 'nvidia', 'milbeaut' : 'socionext', 'uniph' : 'socionext', 'vt8500' : 'vt8500', 'wm8' : 'vt8500', 'xen' : 'xen', 'zx' : 'zte', 'zynq' : 'xilinx', } Rob [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git arm-dts-move-v2
On 02/05/2023 21:40, Rob Herring wrote: > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote: >> >> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote: >>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: >>> >>>> Does your script also cater for .dts files not matching any pattern, >>>> but including a .dtsi file that does match a pattern? >>> >>> I assume I built everything after moving, but maybe not... >>> >>> That's all just "details". First, we need agreement on a) moving >>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've >>> been stuck on a) for being 'too much churn'. >> >> Sorry for missing most of the discussion last week. The script sounds >> fine to me, the only reason I didn't want to do this in the past is that >> we had the plan to move platforms out of the kernel tree to an external >> repository and I wanted to do this platform at a time and also only move >> each one once. I don't think that is going to happen anytime soon now, >> so let's just do your script. >> >> Can you send me the script and/or a pull request of the resulting >> tree based on my soc/dt branch? Everything is merged upstream, >> and I think git-merge would handle the remaining merges with any >> other changes in mainline. > > I've dusted off my script and made a branch[1] with the result. > There's just a couple of fixes needed after the script is run (see the > top commit). The cross arch includes are all fixed up by the script. > dtbs_install maintains a flat install. I compared the number of .dtbs > before and after to check the script. > > I think the only issue remaining is finalizing the mapping of > platforms to subdirs. What I have currently is a mixture of SoC > families and vendors. The most notable are all the Freescale/NXP > platforms, pxa, socfpga, and stm32. It's not consistent with arm64 > either. Once that's finalized, I still need to go update MAINTAINERS. > > Here's the current mapping: > > vendor_map = { > 'alphascale' : 'alphascale', > 'alpine' : 'alpine', > 'artpec' : 'axis', > 'axm' : 'lsi', > 'cx9' : 'cnxt', > 'ecx' : 'calxeda', > 'highbank' : 'calxeda', > 'ep7' : 'cirrus', > 'mxs': 'mxs', > 'imx23': 'mxs', > 'imx28': 'mxs', > 'sun' : 'allwinner', > 'imx': 'imx', > 'e6' : 'imx', > 'e7' : 'imx', > 'mba6' : 'imx', > 'ls': 'fsl', > 'vf': 'fsl', If I remember correctly, Vybrid are a bit closer to iMX than to LS (Layerscape), but it should be Shawn's call (+Cc). > 'qcom': 'qcom', > 'am3' : 'ti', > 'am4' : 'ti', > 'am5' : 'ti', > 'dra' : 'ti', > 'keystone' : 'ti', > 'omap' : 'ti', > 'compulab' : 'ti', > 'logicpd' : 'ti', > 'elpida' : 'ti', > 'motorola' : 'ti', > 'twl' : 'ti', > 'da' : 'ti', > 'dm' : 'ti', > 'nspire' : 'nspire', > 'armada' : 'marvell', > 'dove' : 'marvell', > 'kirkwood' : 'marvell', > 'orion' : 'marvell', > 'mvebu' : 'marvell', > 'mmp' : 'marvell', > 'berlin' : 'berlin', > 'pxa2' : 'pxa', > 'pxa3' : 'pxa', > 'pxa' : 'marvell', > 'arm-' : 'arm', > 'integ' : 'arm', > 'mps' : 'arm', > 've' : 'arm', > 'aspeed' : 'aspeed', > 'ast2' : 'aspeed', > 'facebook' : 'aspeed', > 'ibm' : 'aspeed', > 'openbmc' : 'aspeed', > 'en7' : 'airoha', > 'at91' : 'microchip', > 'sama' : 'microchip', > 'sam9' : 'microchip', > 'usb_' : 'microchip', > 'tny_' : 'microchip', > 'mpa1600' : 'microchip', > 'animeo_ip' : 'microchip', > 'aks-cdu' : 'microchip', > 'ethernut5' : 'microchip', > 'evk-pro3' : 'microchip', > 'pm9g45' : 'microchip', > 'ge86' : 'microchip', > 'bcm' : 'brcm', > 'exynos' : 'samsung', > 's3c' : 'samsung', > 's5p' : 'samsung', For samsung looks good. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > 'gemini' : 'gemini', > 'hi3' : 'hisilicon', > 'hip' : 'hisilicon', > 'hisi' : 'hisilicon', > 'sd5' : 'hisilicon', > 'hpe' : 'hpe', > 'intel': 'intel', > 'mt' : 'mediatek', > 'meson' : 'meson', > 'moxa' : 'moxa', > 'mstar' : 'mstar', > 'nuvo' : 'nuvoton', > 'lpc' : 'lpc', > 'lan96' : 'microchip', > 'owl' : 'actions', > 'ox8' : 'oxsemi', > 'rda' : 'rda', > 'rtd' : 'realtek', > 'r7' : 'renesas', > 'r8' : 'renesas', > 'r9' : 'renesas', > 'emev2' : 'renesas', > 'sh73a' : 'renesas', > 'gr-' : 'renesas', > 'iwg' : 'renesas', > 'rk' : 'rockchip', > 'rv11' : 'rockchip', > 'rockchip' : 'rockchip', > 'socfpga' : 'socfpga', > 'stm' : 'stm32', > 'sti' : 'sti', > 'st-pin' : 'sti', > 'ste' : 'st-ericsson', > 'spear' : 'spear', > 'axp' : 'allwinner', > 'tegra' : 'nvidia', > 'milbeaut' : 'socionext', > 'uniph' : 'socionext', > 'vt8500' : 'vt8500', > 'wm8' : 'vt8500', > 'xen' : 'xen', > 'zx' : 'zte', > 'zynq' : 'xilinx', The rest looks good to me, but I don't know half of these :) Best regards, Krzysztof
On Tue, May 2, 2023 at 9:40 PM Rob Herring <robh+dt@kernel.org> wrote: > I've dusted off my script and made a branch[1] with the result. > There's just a couple of fixes needed after the script is run (see the > top commit). The cross arch includes are all fixed up by the script. > dtbs_install maintains a flat install. I compared the number of .dtbs > before and after to check the script. > > I think the only issue remaining is finalizing the mapping of > platforms to subdirs. What I have currently is a mixture of SoC > families and vendors. The most notable are all the Freescale/NXP > platforms, pxa, socfpga, and stm32. It's not consistent with arm64 > either. Once that's finalized, I still need to go update MAINTAINERS. I see my nits were fixed like I wanted them, and it's now mostly a mix of soc and vendor names that make sense so from my point of view: Acked-by: Linus Walleij <linus.walleij@linaro.org> NB: arch/arm64/boot/dts/arm$ vexpress-v2m-rs1.dtsi -> ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi This still works after the script, yes? Yours, Linus Walleij
On Tue, May 2, 2023 at 4:19 PM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Tue, May 2, 2023 at 9:40 PM Rob Herring <robh+dt@kernel.org> wrote: > > > I've dusted off my script and made a branch[1] with the result. > > There's just a couple of fixes needed after the script is run (see the > > top commit). The cross arch includes are all fixed up by the script. > > dtbs_install maintains a flat install. I compared the number of .dtbs > > before and after to check the script. > > > > I think the only issue remaining is finalizing the mapping of > > platforms to subdirs. What I have currently is a mixture of SoC > > families and vendors. The most notable are all the Freescale/NXP > > platforms, pxa, socfpga, and stm32. It's not consistent with arm64 > > either. Once that's finalized, I still need to go update MAINTAINERS. > > I see my nits were fixed like I wanted them, and it's now mostly a > mix of soc and vendor names that make sense so from my point of view: > Acked-by: Linus Walleij <linus.walleij@linaro.org> > > NB: > arch/arm64/boot/dts/arm$ > vexpress-v2m-rs1.dtsi -> ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi > > This still works after the script, yes? Yes, because in the script I do: git grep -l -F "vexpress-v2m-rs1" arch/arm64/boot/dts | xargs perl -p -i -e "s/vexpress-v2m-rs1/arm\/arm\/vexpress-v2m-rs1/" Rob
> On 2 May 2023, at 8:40 pm, Rob Herring <robh+dt@kernel.org> wrote: > > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote: >> >> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote: >>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: >>> >>>> Does your script also cater for .dts files not matching any pattern, >>>> but including a .dtsi file that does match a pattern? >>> >>> I assume I built everything after moving, but maybe not... >>> >>> That's all just "details". First, we need agreement on a) moving >>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've >>> been stuck on a) for being 'too much churn'. >> >> Sorry for missing most of the discussion last week. The script sounds >> fine to me, the only reason I didn't want to do this in the past is that >> we had the plan to move platforms out of the kernel tree to an external >> repository and I wanted to do this platform at a time and also only move >> each one once. I don't think that is going to happen anytime soon now, >> so let's just do your script. >> >> Can you send me the script and/or a pull request of the resulting >> tree based on my soc/dt branch? Everything is merged upstream, >> and I think git-merge would handle the remaining merges with any >> other changes in mainline. > > I've dusted off my script and made a branch[1] with the result. > There's just a couple of fixes needed after the script is run (see the > top commit). The cross arch includes are all fixed up by the script. > dtbs_install maintains a flat install. I compared the number of .dtbs > before and after to check the script. > > I think the only issue remaining is finalizing the mapping of > platforms to subdirs. What I have currently is a mixture of SoC > families and vendors. The most notable are all the Freescale/NXP > platforms, pxa, socfpga, and stm32. It's not consistent with arm64 > either. Once that's finalized, I still need to go update MAINTAINERS. > > Here's the current mapping: > > vendor_map = { > 'alphascale' : 'alphascale', > 'alpine' : 'alpine', > 'artpec' : 'axis', > 'axm' : 'lsi', > 'cx9' : 'cnxt', > 'ecx' : 'calxeda', > 'highbank' : 'calxeda', > 'ep7' : 'cirrus', > 'mxs': 'mxs', > 'imx23': 'mxs', > 'imx28': 'mxs', > 'sun' : 'allwinner', > 'imx': 'imx', > 'e6' : 'imx', > 'e7' : 'imx', > 'mba6' : 'imx', > 'ls': 'fsl', > 'vf': 'fsl', > 'qcom': 'qcom', > 'am3' : 'ti', > 'am4' : 'ti', > 'am5' : 'ti', > 'dra' : 'ti', > 'keystone' : 'ti', > 'omap' : 'ti', > 'compulab' : 'ti', > 'logicpd' : 'ti', > 'elpida' : 'ti', > 'motorola' : 'ti', > 'twl' : 'ti', > 'da' : 'ti', > 'dm' : 'ti', > 'nspire' : 'nspire', > 'armada' : 'marvell', > 'dove' : 'marvell', > 'kirkwood' : 'marvell', > 'orion' : 'marvell', > 'mvebu' : 'marvell', > 'mmp' : 'marvell', > 'berlin' : 'berlin', > 'pxa2' : 'pxa', > 'pxa3' : 'pxa', > 'pxa' : 'marvell', > 'arm-' : 'arm', > 'integ' : 'arm', > 'mps' : 'arm', > 've' : 'arm', > 'aspeed' : 'aspeed', > 'ast2' : 'aspeed', > 'facebook' : 'aspeed', > 'ibm' : 'aspeed', > 'openbmc' : 'aspeed', > 'en7' : 'airoha', > 'at91' : 'microchip', > 'sama' : 'microchip', > 'sam9' : 'microchip', > 'usb_' : 'microchip', > 'tny_' : 'microchip', > 'mpa1600' : 'microchip', > 'animeo_ip' : 'microchip', > 'aks-cdu' : 'microchip', > 'ethernut5' : 'microchip', > 'evk-pro3' : 'microchip', > 'pm9g45' : 'microchip', > 'ge86' : 'microchip', > 'bcm' : 'brcm', > 'exynos' : 'samsung', > 's3c' : 'samsung', > 's5p' : 'samsung', > 'gemini' : 'gemini', > 'hi3' : 'hisilicon', > 'hip' : 'hisilicon', > 'hisi' : 'hisilicon', > 'sd5' : 'hisilicon', > 'hpe' : 'hpe', > 'intel': 'intel', > 'mt' : 'mediatek', > 'meson' : 'meson', ‘meson’ : ‘amlogic’, ^ to match the SoC vendor name (and arm64) Christian > 'moxa' : 'moxa', > 'mstar' : 'mstar', > 'nuvo' : 'nuvoton', > 'lpc' : 'lpc', > 'lan96' : 'microchip', > 'owl' : 'actions', > 'ox8' : 'oxsemi', > 'rda' : 'rda', > 'rtd' : 'realtek', > 'r7' : 'renesas', > 'r8' : 'renesas', > 'r9' : 'renesas', > 'emev2' : 'renesas', > 'sh73a' : 'renesas', > 'gr-' : 'renesas', > 'iwg' : 'renesas', > 'rk' : 'rockchip', > 'rv11' : 'rockchip', > 'rockchip' : 'rockchip', > 'socfpga' : 'socfpga', > 'stm' : 'stm32', > 'sti' : 'sti', > 'st-pin' : 'sti', > 'ste' : 'st-ericsson', > 'spear' : 'spear', > 'axp' : 'allwinner', > 'tegra' : 'nvidia', > 'milbeaut' : 'socionext', > 'uniph' : 'socionext', > 'vt8500' : 'vt8500', > 'wm8' : 'vt8500', > 'xen' : 'xen', > 'zx' : 'zte', > 'zynq' : 'xilinx', > } > > Rob > > [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git arm-dts-move-v2 > > _______________________________________________ > linux-amlogic mailing list > linux-amlogic@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-amlogic
On 02/05/2023 22:40, Rob Herring wrote: > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote: >> >> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote: >>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: >>> >>>> Does your script also cater for .dts files not matching any pattern, >>>> but including a .dtsi file that does match a pattern? >>> >>> I assume I built everything after moving, but maybe not... >>> >>> That's all just "details". First, we need agreement on a) moving >>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've >>> been stuck on a) for being 'too much churn'. >> >> Sorry for missing most of the discussion last week. The script sounds >> fine to me, the only reason I didn't want to do this in the past is that >> we had the plan to move platforms out of the kernel tree to an external >> repository and I wanted to do this platform at a time and also only move >> each one once. I don't think that is going to happen anytime soon now, >> so let's just do your script. >> >> Can you send me the script and/or a pull request of the resulting >> tree based on my soc/dt branch? Everything is merged upstream, >> and I think git-merge would handle the remaining merges with any >> other changes in mainline. > > I've dusted off my script and made a branch[1] with the result. > There's just a couple of fixes needed after the script is run (see the > top commit). The cross arch includes are all fixed up by the script. > dtbs_install maintains a flat install. I compared the number of .dtbs > before and after to check the script. > > I think the only issue remaining is finalizing the mapping of > platforms to subdirs. What I have currently is a mixture of SoC > families and vendors. The most notable are all the Freescale/NXP > platforms, pxa, socfpga, and stm32. It's not consistent with arm64 > either. Once that's finalized, I still need to go update MAINTAINERS. > > Here's the current mapping: > > vendor_map = { > 'alphascale' : 'alphascale', > 'alpine' : 'alpine', > 'artpec' : 'axis', > 'axm' : 'lsi', > 'cx9' : 'cnxt', > 'ecx' : 'calxeda', > 'highbank' : 'calxeda', > 'ep7' : 'cirrus', > 'mxs': 'mxs', > 'imx23': 'mxs', > 'imx28': 'mxs', > 'sun' : 'allwinner', > 'imx': 'imx', > 'e6' : 'imx', > 'e7' : 'imx', > 'mba6' : 'imx', > 'ls': 'fsl', > 'vf': 'fsl', > 'qcom': 'qcom', > 'am3' : 'ti', > 'am4' : 'ti', > 'am5' : 'ti', > 'dra' : 'ti', > 'keystone' : 'ti', > 'omap' : 'ti', > 'compulab' : 'ti', > 'logicpd' : 'ti', > 'elpida' : 'ti', > 'motorola' : 'ti', > 'twl' : 'ti', > 'da' : 'ti', > 'dm' : 'ti', > 'nspire' : 'nspire', > 'armada' : 'marvell', > 'dove' : 'marvell', > 'kirkwood' : 'marvell', > 'orion' : 'marvell', > 'mvebu' : 'marvell', > 'mmp' : 'marvell', > 'berlin' : 'berlin', > 'pxa2' : 'pxa', > 'pxa3' : 'pxa', > 'pxa' : 'marvell', I'd question if it makes sense to split the pxa line. Yes, it was sold by Intel to Marvell, but IIRC the devices still had some inheritance. So, if we have the 'pxa' subdir, I'd move Marvell PXAs to that dir too. > 'arm-' : 'arm', > 'integ' : 'arm', > 'mps' : 'arm', > 've' : 'arm', > 'aspeed' : 'aspeed', > 'ast2' : 'aspeed', > 'facebook' : 'aspeed', > 'ibm' : 'aspeed', > 'openbmc' : 'aspeed', > 'en7' : 'airoha', > 'at91' : 'microchip', > 'sama' : 'microchip', > 'sam9' : 'microchip', > 'usb_' : 'microchip', > 'tny_' : 'microchip', > 'mpa1600' : 'microchip', > 'animeo_ip' : 'microchip', > 'aks-cdu' : 'microchip', > 'ethernut5' : 'microchip', > 'evk-pro3' : 'microchip', > 'pm9g45' : 'microchip', > 'ge86' : 'microchip', > 'bcm' : 'brcm', > 'exynos' : 'samsung', > 's3c' : 'samsung', > 's5p' : 'samsung', > 'gemini' : 'gemini', > 'hi3' : 'hisilicon', > 'hip' : 'hisilicon', > 'hisi' : 'hisilicon', > 'sd5' : 'hisilicon', > 'hpe' : 'hpe', > 'intel': 'intel', > 'mt' : 'mediatek', > 'meson' : 'meson', > 'moxa' : 'moxa', > 'mstar' : 'mstar', > 'nuvo' : 'nuvoton', > 'lpc' : 'lpc', > 'lan96' : 'microchip', > 'owl' : 'actions', > 'ox8' : 'oxsemi', > 'rda' : 'rda', > 'rtd' : 'realtek', > 'r7' : 'renesas', > 'r8' : 'renesas', > 'r9' : 'renesas', > 'emev2' : 'renesas', > 'sh73a' : 'renesas', > 'gr-' : 'renesas', > 'iwg' : 'renesas', > 'rk' : 'rockchip', > 'rv11' : 'rockchip', > 'rockchip' : 'rockchip', > 'socfpga' : 'socfpga', > 'stm' : 'stm32', > 'sti' : 'sti', > 'st-pin' : 'sti', > 'ste' : 'st-ericsson', > 'spear' : 'spear', > 'axp' : 'allwinner', > 'tegra' : 'nvidia', > 'milbeaut' : 'socionext', > 'uniph' : 'socionext', > 'vt8500' : 'vt8500', > 'wm8' : 'vt8500', > 'xen' : 'xen', > 'zx' : 'zte', > 'zynq' : 'xilinx', > } > > Rob > > [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git arm-dts-move-v2
On 5/2/23 12:40, Rob Herring wrote: > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote: >> >> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote: >>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: >>> >>>> Does your script also cater for .dts files not matching any pattern, >>>> but including a .dtsi file that does match a pattern? >>> >>> I assume I built everything after moving, but maybe not... >>> >>> That's all just "details". First, we need agreement on a) moving >>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've >>> been stuck on a) for being 'too much churn'. >> >> Sorry for missing most of the discussion last week. The script sounds >> fine to me, the only reason I didn't want to do this in the past is that >> we had the plan to move platforms out of the kernel tree to an external >> repository and I wanted to do this platform at a time and also only move >> each one once. I don't think that is going to happen anytime soon now, >> so let's just do your script. >> >> Can you send me the script and/or a pull request of the resulting >> tree based on my soc/dt branch? Everything is merged upstream, >> and I think git-merge would handle the remaining merges with any >> other changes in mainline. > > I've dusted off my script and made a branch[1] with the result. > There's just a couple of fixes needed after the script is run (see the > top commit). The cross arch includes are all fixed up by the script. > dtbs_install maintains a flat install. I compared the number of .dtbs > before and after to check the script. > > I think the only issue remaining is finalizing the mapping of > platforms to subdirs. What I have currently is a mixture of SoC > families and vendors. The most notable are all the Freescale/NXP > platforms, pxa, socfpga, and stm32. It's not consistent with arm64 > either. Once that's finalized, I still need to go update MAINTAINERS. > > Here's the current mapping: > > vendor_map = { > 'alphascale' : 'alphascale', > 'alpine' : 'alpine', > 'artpec' : 'axis', > 'axm' : 'lsi', > 'cx9' : 'cnxt', > 'ecx' : 'calxeda', > 'highbank' : 'calxeda', > 'ep7' : 'cirrus', > 'mxs': 'mxs', > 'imx23': 'mxs', > 'imx28': 'mxs', > 'sun' : 'allwinner', > 'imx': 'imx', > 'e6' : 'imx', > 'e7' : 'imx', > 'mba6' : 'imx', > 'ls': 'fsl', > 'vf': 'fsl', > 'qcom': 'qcom', > 'am3' : 'ti', > 'am4' : 'ti', > 'am5' : 'ti', > 'dra' : 'ti', > 'keystone' : 'ti', > 'omap' : 'ti', > 'compulab' : 'ti', > 'logicpd' : 'ti', > 'elpida' : 'ti', > 'motorola' : 'ti', > 'twl' : 'ti', > 'da' : 'ti', > 'dm' : 'ti', > 'nspire' : 'nspire', > 'armada' : 'marvell', > 'dove' : 'marvell', > 'kirkwood' : 'marvell', > 'orion' : 'marvell', > 'mvebu' : 'marvell', > 'mmp' : 'marvell', > 'berlin' : 'berlin', > 'pxa2' : 'pxa', > 'pxa3' : 'pxa', > 'pxa' : 'marvell', > 'arm-' : 'arm', > 'integ' : 'arm', > 'mps' : 'arm', > 've' : 'arm', > 'aspeed' : 'aspeed', > 'ast2' : 'aspeed', > 'facebook' : 'aspeed', > 'ibm' : 'aspeed', > 'openbmc' : 'aspeed', > 'en7' : 'airoha', > 'at91' : 'microchip', > 'sama' : 'microchip', > 'sam9' : 'microchip', > 'usb_' : 'microchip', > 'tny_' : 'microchip', > 'mpa1600' : 'microchip', > 'animeo_ip' : 'microchip', > 'aks-cdu' : 'microchip', > 'ethernut5' : 'microchip', > 'evk-pro3' : 'microchip', > 'pm9g45' : 'microchip', > 'ge86' : 'microchip', > 'bcm' : 'brcm', How about we use 'broadcom' here, to follow what arm64 does? I could rename arch/mips/boot/dts/brcm to arch/mips/boot/dts/broadcom for consistency, too?
On Tue, May 2, 2023 at 6:02 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > > On 5/2/23 12:40, Rob Herring wrote: > > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote: > >> > >> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote: > >>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > >>> > >>>> Does your script also cater for .dts files not matching any pattern, > >>>> but including a .dtsi file that does match a pattern? > >>> > >>> I assume I built everything after moving, but maybe not... > >>> > >>> That's all just "details". First, we need agreement on a) moving > >>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've > >>> been stuck on a) for being 'too much churn'. > >> > >> Sorry for missing most of the discussion last week. The script sounds > >> fine to me, the only reason I didn't want to do this in the past is that > >> we had the plan to move platforms out of the kernel tree to an external > >> repository and I wanted to do this platform at a time and also only move > >> each one once. I don't think that is going to happen anytime soon now, > >> so let's just do your script. > >> > >> Can you send me the script and/or a pull request of the resulting > >> tree based on my soc/dt branch? Everything is merged upstream, > >> and I think git-merge would handle the remaining merges with any > >> other changes in mainline. > > > > I've dusted off my script and made a branch[1] with the result. > > There's just a couple of fixes needed after the script is run (see the > > top commit). The cross arch includes are all fixed up by the script. > > dtbs_install maintains a flat install. I compared the number of .dtbs > > before and after to check the script. > > > > I think the only issue remaining is finalizing the mapping of > > platforms to subdirs. What I have currently is a mixture of SoC > > families and vendors. The most notable are all the Freescale/NXP > > platforms, pxa, socfpga, and stm32. It's not consistent with arm64 > > either. Once that's finalized, I still need to go update MAINTAINERS. > > > > Here's the current mapping: > > > > vendor_map = { > > 'alphascale' : 'alphascale', > > 'alpine' : 'alpine', > > 'artpec' : 'axis', > > 'axm' : 'lsi', > > 'cx9' : 'cnxt', > > 'ecx' : 'calxeda', > > 'highbank' : 'calxeda', > > 'ep7' : 'cirrus', > > 'mxs': 'mxs', > > 'imx23': 'mxs', > > 'imx28': 'mxs', > > 'sun' : 'allwinner', > > 'imx': 'imx', > > 'e6' : 'imx', > > 'e7' : 'imx', > > 'mba6' : 'imx', > > 'ls': 'fsl', > > 'vf': 'fsl', > > 'qcom': 'qcom', > > 'am3' : 'ti', > > 'am4' : 'ti', > > 'am5' : 'ti', > > 'dra' : 'ti', > > 'keystone' : 'ti', > > 'omap' : 'ti', > > 'compulab' : 'ti', > > 'logicpd' : 'ti', > > 'elpida' : 'ti', > > 'motorola' : 'ti', > > 'twl' : 'ti', > > 'da' : 'ti', > > 'dm' : 'ti', > > 'nspire' : 'nspire', > > 'armada' : 'marvell', > > 'dove' : 'marvell', > > 'kirkwood' : 'marvell', > > 'orion' : 'marvell', > > 'mvebu' : 'marvell', > > 'mmp' : 'marvell', > > 'berlin' : 'berlin', > > 'pxa2' : 'pxa', > > 'pxa3' : 'pxa', > > 'pxa' : 'marvell', > > 'arm-' : 'arm', > > 'integ' : 'arm', > > 'mps' : 'arm', > > 've' : 'arm', > > 'aspeed' : 'aspeed', > > 'ast2' : 'aspeed', > > 'facebook' : 'aspeed', > > 'ibm' : 'aspeed', > > 'openbmc' : 'aspeed', > > 'en7' : 'airoha', > > 'at91' : 'microchip', > > 'sama' : 'microchip', > > 'sam9' : 'microchip', > > 'usb_' : 'microchip', > > 'tny_' : 'microchip', > > 'mpa1600' : 'microchip', > > 'animeo_ip' : 'microchip', > > 'aks-cdu' : 'microchip', > > 'ethernut5' : 'microchip', > > 'evk-pro3' : 'microchip', > > 'pm9g45' : 'microchip', > > 'ge86' : 'microchip', > > 'bcm' : 'brcm', > > How about we use 'broadcom' here, to follow what arm64 does? I could > rename arch/mips/boot/dts/brcm to arch/mips/boot/dts/broadcom for > consistency, too? Okay, though if starting clean I'd somewhat prefer to use the vendor prefix. I guess since arm and arm64 share dtsi files, they should match. Rob
On Tue, May 2, 2023 at 5:52 PM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > > On 02/05/2023 22:40, Rob Herring wrote: > > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote: > >> > >> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote: > >>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > >>> > >>>> Does your script also cater for .dts files not matching any pattern, > >>>> but including a .dtsi file that does match a pattern? > >>> > >>> I assume I built everything after moving, but maybe not... > >>> > >>> That's all just "details". First, we need agreement on a) moving > >>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've > >>> been stuck on a) for being 'too much churn'. > >> > >> Sorry for missing most of the discussion last week. The script sounds > >> fine to me, the only reason I didn't want to do this in the past is that > >> we had the plan to move platforms out of the kernel tree to an external > >> repository and I wanted to do this platform at a time and also only move > >> each one once. I don't think that is going to happen anytime soon now, > >> so let's just do your script. > >> > >> Can you send me the script and/or a pull request of the resulting > >> tree based on my soc/dt branch? Everything is merged upstream, > >> and I think git-merge would handle the remaining merges with any > >> other changes in mainline. > > > > I've dusted off my script and made a branch[1] with the result. > > There's just a couple of fixes needed after the script is run (see the > > top commit). The cross arch includes are all fixed up by the script. > > dtbs_install maintains a flat install. I compared the number of .dtbs > > before and after to check the script. > > > > I think the only issue remaining is finalizing the mapping of > > platforms to subdirs. What I have currently is a mixture of SoC > > families and vendors. The most notable are all the Freescale/NXP > > platforms, pxa, socfpga, and stm32. It's not consistent with arm64 > > either. Once that's finalized, I still need to go update MAINTAINERS. > > > > Here's the current mapping: > > > > vendor_map = { > > 'alphascale' : 'alphascale', > > 'alpine' : 'alpine', > > 'artpec' : 'axis', > > 'axm' : 'lsi', > > 'cx9' : 'cnxt', > > 'ecx' : 'calxeda', > > 'highbank' : 'calxeda', > > 'ep7' : 'cirrus', > > 'mxs': 'mxs', > > 'imx23': 'mxs', > > 'imx28': 'mxs', > > 'sun' : 'allwinner', > > 'imx': 'imx', > > 'e6' : 'imx', > > 'e7' : 'imx', > > 'mba6' : 'imx', > > 'ls': 'fsl', > > 'vf': 'fsl', > > 'qcom': 'qcom', > > 'am3' : 'ti', > > 'am4' : 'ti', > > 'am5' : 'ti', > > 'dra' : 'ti', > > 'keystone' : 'ti', > > 'omap' : 'ti', > > 'compulab' : 'ti', > > 'logicpd' : 'ti', > > 'elpida' : 'ti', > > 'motorola' : 'ti', > > 'twl' : 'ti', > > 'da' : 'ti', > > 'dm' : 'ti', > > 'nspire' : 'nspire', > > 'armada' : 'marvell', > > 'dove' : 'marvell', > > 'kirkwood' : 'marvell', > > 'orion' : 'marvell', > > 'mvebu' : 'marvell', > > 'mmp' : 'marvell', > > 'berlin' : 'berlin', > > 'pxa2' : 'pxa', > > 'pxa3' : 'pxa', > > 'pxa' : 'marvell', > > I'd question if it makes sense to split the pxa line. Yes, it was sold > by Intel to Marvell, but IIRC the devices still had some inheritance. > So, if we have the 'pxa' subdir, I'd move Marvell PXAs to that dir too. I think I probably split it because it was different maintainers. Though it doesn't look like pxa168 or pxa910 have any maintainer. They are a mixture of pxa and mmp I think. Rob
On Tue, May 02, 2023 at 10:02:03PM +0200, Krzysztof Kozlowski wrote: > On 02/05/2023 21:40, Rob Herring wrote: > > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote: > >> > >> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote: > >>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > >>> > >>>> Does your script also cater for .dts files not matching any pattern, > >>>> but including a .dtsi file that does match a pattern? > >>> > >>> I assume I built everything after moving, but maybe not... > >>> > >>> That's all just "details". First, we need agreement on a) moving > >>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've > >>> been stuck on a) for being 'too much churn'. > >> > >> Sorry for missing most of the discussion last week. The script sounds > >> fine to me, the only reason I didn't want to do this in the past is that > >> we had the plan to move platforms out of the kernel tree to an external > >> repository and I wanted to do this platform at a time and also only move > >> each one once. I don't think that is going to happen anytime soon now, > >> so let's just do your script. > >> > >> Can you send me the script and/or a pull request of the resulting > >> tree based on my soc/dt branch? Everything is merged upstream, > >> and I think git-merge would handle the remaining merges with any > >> other changes in mainline. > > > > I've dusted off my script and made a branch[1] with the result. > > There's just a couple of fixes needed after the script is run (see the > > top commit). The cross arch includes are all fixed up by the script. > > dtbs_install maintains a flat install. I compared the number of .dtbs > > before and after to check the script. > > > > I think the only issue remaining is finalizing the mapping of > > platforms to subdirs. What I have currently is a mixture of SoC > > families and vendors. The most notable are all the Freescale/NXP > > platforms, pxa, socfpga, and stm32. It's not consistent with arm64 > > either. Once that's finalized, I still need to go update MAINTAINERS. > > > > Here's the current mapping: > > > > vendor_map = { > > 'alphascale' : 'alphascale', > > 'alpine' : 'alpine', > > 'artpec' : 'axis', > > 'axm' : 'lsi', > > 'cx9' : 'cnxt', > > 'ecx' : 'calxeda', > > 'highbank' : 'calxeda', > > 'ep7' : 'cirrus', > > 'mxs': 'mxs', > > 'imx23': 'mxs', > > 'imx28': 'mxs', > > 'sun' : 'allwinner', > > 'imx': 'imx', > > 'e6' : 'imx', > > 'e7' : 'imx', > > 'mba6' : 'imx', > > 'ls': 'fsl', > > 'vf': 'fsl', > > If I remember correctly, Vybrid are a bit closer to iMX than to LS > (Layerscape), but it should be Shawn's call (+Cc). I would suggest to have all Freescale/NXP platforms in a single directory, which includes all mxs, imx, fsl ones. Shawn > > > 'qcom': 'qcom', > > 'am3' : 'ti', > > 'am4' : 'ti', > > 'am5' : 'ti', > > 'dra' : 'ti', > > 'keystone' : 'ti', > > 'omap' : 'ti', > > 'compulab' : 'ti', > > 'logicpd' : 'ti', > > 'elpida' : 'ti', > > 'motorola' : 'ti', > > 'twl' : 'ti', > > 'da' : 'ti', > > 'dm' : 'ti', > > 'nspire' : 'nspire', > > 'armada' : 'marvell', > > 'dove' : 'marvell', > > 'kirkwood' : 'marvell', > > 'orion' : 'marvell', > > 'mvebu' : 'marvell', > > 'mmp' : 'marvell', > > 'berlin' : 'berlin', > > 'pxa2' : 'pxa', > > 'pxa3' : 'pxa', > > 'pxa' : 'marvell', > > 'arm-' : 'arm', > > 'integ' : 'arm', > > 'mps' : 'arm', > > 've' : 'arm', > > 'aspeed' : 'aspeed', > > 'ast2' : 'aspeed', > > 'facebook' : 'aspeed', > > 'ibm' : 'aspeed', > > 'openbmc' : 'aspeed', > > 'en7' : 'airoha', > > 'at91' : 'microchip', > > 'sama' : 'microchip', > > 'sam9' : 'microchip', > > 'usb_' : 'microchip', > > 'tny_' : 'microchip', > > 'mpa1600' : 'microchip', > > 'animeo_ip' : 'microchip', > > 'aks-cdu' : 'microchip', > > 'ethernut5' : 'microchip', > > 'evk-pro3' : 'microchip', > > 'pm9g45' : 'microchip', > > 'ge86' : 'microchip', > > 'bcm' : 'brcm', > > 'exynos' : 'samsung', > > 's3c' : 'samsung', > > 's5p' : 'samsung', > > For samsung looks good. > > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > > 'gemini' : 'gemini', > > 'hi3' : 'hisilicon', > > 'hip' : 'hisilicon', > > 'hisi' : 'hisilicon', > > 'sd5' : 'hisilicon', > > 'hpe' : 'hpe', > > 'intel': 'intel', > > 'mt' : 'mediatek', > > 'meson' : 'meson', > > 'moxa' : 'moxa', > > 'mstar' : 'mstar', > > 'nuvo' : 'nuvoton', > > 'lpc' : 'lpc', > > 'lan96' : 'microchip', > > 'owl' : 'actions', > > 'ox8' : 'oxsemi', > > 'rda' : 'rda', > > 'rtd' : 'realtek', > > 'r7' : 'renesas', > > 'r8' : 'renesas', > > 'r9' : 'renesas', > > 'emev2' : 'renesas', > > 'sh73a' : 'renesas', > > 'gr-' : 'renesas', > > 'iwg' : 'renesas', > > 'rk' : 'rockchip', > > 'rv11' : 'rockchip', > > 'rockchip' : 'rockchip', > > 'socfpga' : 'socfpga', > > 'stm' : 'stm32', > > 'sti' : 'sti', > > 'st-pin' : 'sti', > > 'ste' : 'st-ericsson', > > 'spear' : 'spear', > > 'axp' : 'allwinner', > > 'tegra' : 'nvidia', > > 'milbeaut' : 'socionext', > > 'uniph' : 'socionext', > > 'vt8500' : 'vt8500', > > 'wm8' : 'vt8500', > > 'xen' : 'xen', > > 'zx' : 'zte', > > 'zynq' : 'xilinx', > > The rest looks good to me, but I don't know half of these :) > > Best regards, > Krzysztof >
* Rob Herring <robh+dt@kernel.org> [230502 19:40]: > I've dusted off my script and made a branch[1] with the result. > There's just a couple of fixes needed after the script is run (see the > top commit). The cross arch includes are all fixed up by the script. > dtbs_install maintains a flat install. I compared the number of .dtbs > before and after to check the script. ... > [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git arm-dts-move-v2 Looks good to me, thanks for doing this. Regards, Tony
Hi Rob, On Tue, May 2, 2023 at 9:40 PM Rob Herring <robh+dt@kernel.org> wrote: > 'r7' : 'renesas', > 'r8' : 'renesas', > 'r9' : 'renesas', > 'emev2' : 'renesas', > 'sh73a' : 'renesas', > 'gr-' : 'renesas', > 'iwg' : 'renesas', Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Gr{oetje,eeting}s, Geert
On Wed, May 3, 2023, at 03:17, Rob Herring wrote: > On Tue, May 2, 2023 at 5:52 PM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: >> On 02/05/2023 22:40, Rob Herring wrote: >> > 'berlin' : 'berlin', >> > 'pxa2' : 'pxa', >> > 'pxa3' : 'pxa', >> > 'pxa' : 'marvell', >> >> I'd question if it makes sense to split the pxa line. Yes, it was sold >> by Intel to Marvell, but IIRC the devices still had some inheritance. >> So, if we have the 'pxa' subdir, I'd move Marvell PXAs to that dir too. > > I think I probably split it because it was different maintainers. > Though it doesn't look like pxa168 or pxa910 have any maintainer. They > are a mixture of pxa and mmp I think. I think the original split here is probably the best we can do, but there is no good way to do it because of the confusing naming and the problem that there is no clear line between pxa and mmp. As far as I can tell, the release timeline was: Intel pxa2xx (mach-pxa, xscale, still exists) Intel pxa3xx (mach-pxa, xscale, still exists) Intel pxa90x (never merged) Marvell pxa93x (mach-pxa, xscale, removed in Linux-6.3, no DT) Marvell pxa92x (never merged) Marvell pxa91x (mach-mmp, pj1, still exists) Marvell pxa168 (mach-mmp, pj1, still exists) Marvell pxa95x (mach-pxa, pj4, long gone) Marvell pxa688 (mach-mmp, pj4, known as mmp2) So with pxa93x out of the picture, we can simplify it as using 'pxa' as the name for all the above chips with an Intel XScale core, and 'marvell' for all the other ones that have a Marvell core and exist in mach-mmp. Arnd
On 03/05/2023 00:01, Christian Hewitt wrote: > > >> On 2 May 2023, at 8:40 pm, Rob Herring <robh+dt@kernel.org> wrote: >> >> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote: >>> >>> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote: >>>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: >>>> >>>>> Does your script also cater for .dts files not matching any pattern, >>>>> but including a .dtsi file that does match a pattern? >>>> >>>> I assume I built everything after moving, but maybe not... >>>> >>>> That's all just "details". First, we need agreement on a) moving >>>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've >>>> been stuck on a) for being 'too much churn'. >>> >>> Sorry for missing most of the discussion last week. The script sounds >>> fine to me, the only reason I didn't want to do this in the past is that >>> we had the plan to move platforms out of the kernel tree to an external >>> repository and I wanted to do this platform at a time and also only move >>> each one once. I don't think that is going to happen anytime soon now, >>> so let's just do your script. >>> >>> Can you send me the script and/or a pull request of the resulting >>> tree based on my soc/dt branch? Everything is merged upstream, >>> and I think git-merge would handle the remaining merges with any >>> other changes in mainline. >> >> I've dusted off my script and made a branch[1] with the result. >> There's just a couple of fixes needed after the script is run (see the >> top commit). The cross arch includes are all fixed up by the script. >> dtbs_install maintains a flat install. I compared the number of .dtbs >> before and after to check the script. >> >> I think the only issue remaining is finalizing the mapping of >> platforms to subdirs. What I have currently is a mixture of SoC >> families and vendors. The most notable are all the Freescale/NXP >> platforms, pxa, socfpga, and stm32. It's not consistent with arm64 >> either. Once that's finalized, I still need to go update MAINTAINERS. >> >> Here's the current mapping: >> >> vendor_map = { >> 'alphascale' : 'alphascale', >> 'alpine' : 'alpine', >> 'artpec' : 'axis', >> 'axm' : 'lsi', >> 'cx9' : 'cnxt', >> 'ecx' : 'calxeda', >> 'highbank' : 'calxeda', >> 'ep7' : 'cirrus', >> 'mxs': 'mxs', >> 'imx23': 'mxs', >> 'imx28': 'mxs', >> 'sun' : 'allwinner', >> 'imx': 'imx', >> 'e6' : 'imx', >> 'e7' : 'imx', >> 'mba6' : 'imx', >> 'ls': 'fsl', >> 'vf': 'fsl', >> 'qcom': 'qcom', >> 'am3' : 'ti', >> 'am4' : 'ti', >> 'am5' : 'ti', >> 'dra' : 'ti', >> 'keystone' : 'ti', >> 'omap' : 'ti', >> 'compulab' : 'ti', >> 'logicpd' : 'ti', >> 'elpida' : 'ti', >> 'motorola' : 'ti', >> 'twl' : 'ti', >> 'da' : 'ti', >> 'dm' : 'ti', >> 'nspire' : 'nspire', >> 'armada' : 'marvell', >> 'dove' : 'marvell', >> 'kirkwood' : 'marvell', >> 'orion' : 'marvell', >> 'mvebu' : 'marvell', >> 'mmp' : 'marvell', >> 'berlin' : 'berlin', >> 'pxa2' : 'pxa', >> 'pxa3' : 'pxa', >> 'pxa' : 'marvell', >> 'arm-' : 'arm', >> 'integ' : 'arm', >> 'mps' : 'arm', >> 've' : 'arm', >> 'aspeed' : 'aspeed', >> 'ast2' : 'aspeed', >> 'facebook' : 'aspeed', >> 'ibm' : 'aspeed', >> 'openbmc' : 'aspeed', >> 'en7' : 'airoha', >> 'at91' : 'microchip', >> 'sama' : 'microchip', >> 'sam9' : 'microchip', >> 'usb_' : 'microchip', >> 'tny_' : 'microchip', >> 'mpa1600' : 'microchip', >> 'animeo_ip' : 'microchip', >> 'aks-cdu' : 'microchip', >> 'ethernut5' : 'microchip', >> 'evk-pro3' : 'microchip', >> 'pm9g45' : 'microchip', >> 'ge86' : 'microchip', >> 'bcm' : 'brcm', >> 'exynos' : 'samsung', >> 's3c' : 'samsung', >> 's5p' : 'samsung', >> 'gemini' : 'gemini', >> 'hi3' : 'hisilicon', >> 'hip' : 'hisilicon', >> 'hisi' : 'hisilicon', >> 'sd5' : 'hisilicon', >> 'hpe' : 'hpe', >> 'intel': 'intel', >> 'mt' : 'mediatek', >> 'meson' : 'meson', > > ‘meson’ : ‘amlogic’, > > ^ to match the SoC vendor name (and arm64) Ack we're trying to get rid of meson, so it would be time. Neil > > Christian > >> 'moxa' : 'moxa', >> 'mstar' : 'mstar', >> 'nuvo' : 'nuvoton', >> 'lpc' : 'lpc', >> 'lan96' : 'microchip', >> 'owl' : 'actions', >> 'ox8' : 'oxsemi', >> 'rda' : 'rda', >> 'rtd' : 'realtek', >> 'r7' : 'renesas', >> 'r8' : 'renesas', >> 'r9' : 'renesas', >> 'emev2' : 'renesas', >> 'sh73a' : 'renesas', >> 'gr-' : 'renesas', >> 'iwg' : 'renesas', >> 'rk' : 'rockchip', >> 'rv11' : 'rockchip', >> 'rockchip' : 'rockchip', >> 'socfpga' : 'socfpga', >> 'stm' : 'stm32', >> 'sti' : 'sti', >> 'st-pin' : 'sti', >> 'ste' : 'st-ericsson', >> 'spear' : 'spear', >> 'axp' : 'allwinner', >> 'tegra' : 'nvidia', >> 'milbeaut' : 'socionext', >> 'uniph' : 'socionext', >> 'vt8500' : 'vt8500', >> 'wm8' : 'vt8500', >> 'xen' : 'xen', >> 'zx' : 'zte', >> 'zynq' : 'xilinx', >> } >> >> Rob >> >> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git arm-dts-move-v2 >> >> _______________________________________________ >> linux-amlogic mailing list >> linux-amlogic@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-amlogic >
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
On Tue, May 2, 2023, at 21:40, Rob Herring wrote: > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote: > vendor_map = { > 'alphascale' : 'alphascale', > 'alpine' : 'alpine', I would make this one 'amazon' if we go with current manufacturers. > 'nspire' : 'nspire', nspire is the name of the end-user product, so that doesn't quite fit. The SoC was apparently an LSI logic Zevio, which is now owned by Broadcom. > 'mvebu' : 'marvell', > 'mmp' : 'marvell', > 'berlin' : 'berlin', While berlin is related to pxa/mmp, this one is now owned by Synaptics, and the 64-bit versions are already in the synaptics subdir, so I'd go with teh same here. > 'openbmc' : 'aspeed', > 'en7' : 'airoha', airoha is a separate company now, but the hardware is still shared with mediatek, so we could consider lumping it into that subdir, but a separate one may be better long-term. > 'gemini' : 'gemini', This one is also a product name, not a company. Apparently, gemini was originally made by Storm Semiconductor, and then by Cortina, which was subsequently acquired by Inphi, and that ended up in Marvell after the product was already discontinued. Out of the four, I'd probably go with 'cortina' as the directory name. > 'meson' : 'meson', -> amlogic > 'moxa' : 'moxa', > 'mstar' : 'mstar', -> sigmastar > 'nuvo' : 'nuvoton', > 'lpc' : 'lpc', -> nxp > 'lan96' : 'microchip', > 'owl' : 'actions', > 'ox8' : 'oxsemi', > 'rda' : 'rda', -> unisoc > 'rtd' : 'realtek', > 'r7' : 'renesas', > 'r8' : 'renesas', > 'r9' : 'renesas', > 'emev2' : 'renesas', > 'sh73a' : 'renesas', > 'gr-' : 'renesas', > 'iwg' : 'renesas', > 'rk' : 'rockchip', > 'rv11' : 'rockchip', > 'rockchip' : 'rockchip', > 'socfpga' : 'socfpga', -> intel > 'stm' : 'stm32', > 'sti' : 'sti', > 'st-pin' : 'sti', > 'ste' : 'st-ericsson', > 'spear' : 'spear', I would put all five of these into 'st'. The ux500 was developed in st-ericsson, but last sold by st, and the other ones are all original st products. Arnd
On Tue, May 02, 2023 at 02:40:19PM -0500, Rob Herring wrote: > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote: > I've dusted off my script and made a branch[1] with the result. > There's just a couple of fixes needed after the script is run (see the > top commit). The cross arch includes are all fixed up by the script. > dtbs_install maintains a flat install. I compared the number of .dtbs > before and after to check the script. > > I think the only issue remaining is finalizing the mapping of > platforms to subdirs. What I have currently is a mixture of SoC > families and vendors. The most notable are all the Freescale/NXP > platforms, pxa, socfpga, and stm32. It's not consistent with arm64 > either. Once that's finalized, I still need to go update MAINTAINERS. > > Here's the current mapping: > > vendor_map = { > [...] > 'artpec' : 'axis', Looks good for our platforms also, thanks! /^JN - Jesper Nilsson
On Wed, 3 May 2023 at 13:39, Arnd Bergmann <arnd@arndb.de> wrote: > > On Wed, May 3, 2023, at 03:17, Rob Herring wrote: > > On Tue, May 2, 2023 at 5:52 PM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > >> On 02/05/2023 22:40, Rob Herring wrote: > >> > 'berlin' : 'berlin', > >> > 'pxa2' : 'pxa', > >> > 'pxa3' : 'pxa', > >> > 'pxa' : 'marvell', > >> > >> I'd question if it makes sense to split the pxa line. Yes, it was sold > >> by Intel to Marvell, but IIRC the devices still had some inheritance. > >> So, if we have the 'pxa' subdir, I'd move Marvell PXAs to that dir too. > > > > I think I probably split it because it was different maintainers. > > Though it doesn't look like pxa168 or pxa910 have any maintainer. They > > are a mixture of pxa and mmp I think. > > I think the original split here is probably the best we can do, > but there is no good way to do it because of the confusing naming > and the problem that there is no clear line between pxa and mmp. > As far as I can tell, the release timeline was: > > Intel pxa2xx (mach-pxa, xscale, still exists) > Intel pxa3xx (mach-pxa, xscale, still exists) > Intel pxa90x (never merged) > Marvell pxa93x (mach-pxa, xscale, removed in Linux-6.3, no DT) > Marvell pxa92x (never merged) > Marvell pxa91x (mach-mmp, pj1, still exists) > Marvell pxa168 (mach-mmp, pj1, still exists) > Marvell pxa95x (mach-pxa, pj4, long gone) > Marvell pxa688 (mach-mmp, pj4, known as mmp2) > > So with pxa93x out of the picture, we can simplify it as using > 'pxa' as the name for all the above chips with an Intel XScale > core, and 'marvell' for all the other ones that have a Marvell > core and exist in mach-mmp. Should it be 'intel' for pxa[23]xx then? > > Arnd
On Wed, May 3, 2023, at 14:13, Dmitry Baryshkov wrote: > On Wed, 3 May 2023 at 13:39, Arnd Bergmann <arnd@arndb.de> wrote: >> So with pxa93x out of the picture, we can simplify it as using >> 'pxa' as the name for all the above chips with an Intel XScale >> core, and 'marvell' for all the other ones that have a Marvell >> core and exist in mach-mmp. > > Should it be 'intel' for pxa[23]xx then? Probably yes, that would put it next to ixp4xx, which makes a lot of sense (same vintage, same cpu core), though it is a bit funny to have these together with lsi axxia and altera socfpga, both of which are also in the intel directory. socfpga is of course the only one that anybody at Intel cares about these days. Arnd
On Wed, May 3, 2023 at 6:02 AM Arnd Bergmann <arnd@arndb.de> wrote: > > On Tue, May 2, 2023, at 21:40, Rob Herring wrote: > > On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote: > > > vendor_map = { > > 'alphascale' : 'alphascale', > > 'alpine' : 'alpine', > > I would make this one 'amazon' if we go with current manufacturers. > > > 'nspire' : 'nspire', > > nspire is the name of the end-user product, so that doesn't quite > fit. The SoC was apparently an LSI logic Zevio, which is now owned > by Broadcom. I'm inclined to leave it. I put it in the category of a one-off thing that's not sharing anything > > 'mvebu' : 'marvell', > > 'mmp' : 'marvell', > > 'berlin' : 'berlin', > > While berlin is related to pxa/mmp, this one is now owned > by Synaptics, and the 64-bit versions are already in the > synaptics subdir, so I'd go with teh same here. > > > 'openbmc' : 'aspeed', > > 'en7' : 'airoha', > > airoha is a separate company now, but the hardware is still > shared with mediatek, so we could consider lumping it into > that subdir, but a separate one may be better long-term. > > > 'gemini' : 'gemini', > > This one is also a product name, not a company. Apparently, > gemini was originally made by Storm Semiconductor, and then > by Cortina, which was subsequently acquired by Inphi, and that ended > up in Marvell after the product was already discontinued. > > Out of the four, I'd probably go with 'cortina' as the > directory name. I had 'cortina' previously. Linus wanted gemini... Rob
On Wed, May 3, 2023 at 7:19 AM Arnd Bergmann <arnd@arndb.de> wrote: > > On Wed, May 3, 2023, at 14:13, Dmitry Baryshkov wrote: > > On Wed, 3 May 2023 at 13:39, Arnd Bergmann <arnd@arndb.de> wrote: > > >> So with pxa93x out of the picture, we can simplify it as using > >> 'pxa' as the name for all the above chips with an Intel XScale > >> core, and 'marvell' for all the other ones that have a Marvell > >> core and exist in mach-mmp. > > > > Should it be 'intel' for pxa[23]xx then? > > Probably yes, that would put it next to ixp4xx, which makes > a lot of sense (same vintage, same cpu core), though it is > a bit funny to have these together with lsi axxia and > altera socfpga, both of which are also in the intel > directory. socfpga is of course the only one that anybody > at Intel cares about these days. We could do a second level of directories here: intel/pxa/ intel/ixp/ intel/socfpga/ arm64 broadcom dts files are structured that way. Rob
On Wed, May 3, 2023 at 1:03 PM Arnd Bergmann <arnd@arndb.de> wrote: > > 'gemini' : 'gemini', > > This one is also a product name, not a company. Apparently, > gemini was originally made by Storm Semiconductor, and then > by Cortina, which was subsequently acquired by Inphi, and that ended > up in Marvell after the product was already discontinued. > > Out of the four, I'd probably go with 'cortina' as the > directory name. > StorLink was the initial company, thus SL3516, SL3512 the name of the chips. Then that company changed name to Storm Semiconductor. Git acquired by Cortina. Then Inphi acquired Cortina. Then Marvell scooped up the IP. If we *have* to use a company name I would use storlink, because the chips are named after that. Yours, Linus Walleij
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
On Wed, May 3, 2023 at 10:37 PM Arnd Bergmann <arnd@arndb.de> wrote: > On Wed, May 3, 2023, at 15:16, Rob Herring wrote: > > > We could do a second level of directories here: > > Works for me, but at that point, I'd really also want to do it > for nxp with its five or more product lines (mxs, imx, lpc, > s32, layerscape, vybrid) > > > intel/pxa/ > > intel/ixp/ > > intel/socfpga/ > > and intel/axxia I guess. This looks neat. I like it. Yours, Linus Walleij
On Wed, May 3, 2023 at 3:37 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Wed, May 3, 2023, at 15:16, Rob Herring wrote: > > > We could do a second level of directories here: > > Works for me, but at that point, I'd really also want to do it > for nxp with its five or more product lines (mxs, imx, lpc, > s32, layerscape, vybrid) And marvell, microchip(lan96), ti, and broadcom probably. I think I withdraw my suggestion... Rob
On 5/2/23 18:04, Rob Herring wrote: > On Tue, May 2, 2023 at 6:02 PM Florian Fainelli <f.fainelli@gmail.com> wrote: >> >> On 5/2/23 12:40, Rob Herring wrote: >>> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote: >>>> >>>> On Tue, Apr 25, 2023, at 17:57, Rob Herring wrote: >>>>> On Tue, Apr 25, 2023 at 2:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: >>>>> >>>>>> Does your script also cater for .dts files not matching any pattern, >>>>>> but including a .dtsi file that does match a pattern? >>>>> >>>>> I assume I built everything after moving, but maybe not... >>>>> >>>>> That's all just "details". First, we need agreement on a) moving >>>>> things to subdirs and b) doing it 1-by-1 or all at once. So far we've >>>>> been stuck on a) for being 'too much churn'. >>>> >>>> Sorry for missing most of the discussion last week. The script sounds >>>> fine to me, the only reason I didn't want to do this in the past is that >>>> we had the plan to move platforms out of the kernel tree to an external >>>> repository and I wanted to do this platform at a time and also only move >>>> each one once. I don't think that is going to happen anytime soon now, >>>> so let's just do your script. >>>> >>>> Can you send me the script and/or a pull request of the resulting >>>> tree based on my soc/dt branch? Everything is merged upstream, >>>> and I think git-merge would handle the remaining merges with any >>>> other changes in mainline. >>> >>> I've dusted off my script and made a branch[1] with the result. >>> There's just a couple of fixes needed after the script is run (see the >>> top commit). The cross arch includes are all fixed up by the script. >>> dtbs_install maintains a flat install. I compared the number of .dtbs >>> before and after to check the script. >>> >>> I think the only issue remaining is finalizing the mapping of >>> platforms to subdirs. What I have currently is a mixture of SoC >>> families and vendors. The most notable are all the Freescale/NXP >>> platforms, pxa, socfpga, and stm32. It's not consistent with arm64 >>> either. Once that's finalized, I still need to go update MAINTAINERS. >>> >>> Here's the current mapping: >>> >>> vendor_map = { >>> 'alphascale' : 'alphascale', >>> 'alpine' : 'alpine', >>> 'artpec' : 'axis', >>> 'axm' : 'lsi', >>> 'cx9' : 'cnxt', >>> 'ecx' : 'calxeda', >>> 'highbank' : 'calxeda', >>> 'ep7' : 'cirrus', >>> 'mxs': 'mxs', >>> 'imx23': 'mxs', >>> 'imx28': 'mxs', >>> 'sun' : 'allwinner', >>> 'imx': 'imx', >>> 'e6' : 'imx', >>> 'e7' : 'imx', >>> 'mba6' : 'imx', >>> 'ls': 'fsl', >>> 'vf': 'fsl', >>> 'qcom': 'qcom', >>> 'am3' : 'ti', >>> 'am4' : 'ti', >>> 'am5' : 'ti', >>> 'dra' : 'ti', >>> 'keystone' : 'ti', >>> 'omap' : 'ti', >>> 'compulab' : 'ti', >>> 'logicpd' : 'ti', >>> 'elpida' : 'ti', >>> 'motorola' : 'ti', >>> 'twl' : 'ti', >>> 'da' : 'ti', >>> 'dm' : 'ti', >>> 'nspire' : 'nspire', >>> 'armada' : 'marvell', >>> 'dove' : 'marvell', >>> 'kirkwood' : 'marvell', >>> 'orion' : 'marvell', >>> 'mvebu' : 'marvell', >>> 'mmp' : 'marvell', >>> 'berlin' : 'berlin', >>> 'pxa2' : 'pxa', >>> 'pxa3' : 'pxa', >>> 'pxa' : 'marvell', >>> 'arm-' : 'arm', >>> 'integ' : 'arm', >>> 'mps' : 'arm', >>> 've' : 'arm', >>> 'aspeed' : 'aspeed', >>> 'ast2' : 'aspeed', >>> 'facebook' : 'aspeed', >>> 'ibm' : 'aspeed', >>> 'openbmc' : 'aspeed', >>> 'en7' : 'airoha', >>> 'at91' : 'microchip', >>> 'sama' : 'microchip', >>> 'sam9' : 'microchip', >>> 'usb_' : 'microchip', >>> 'tny_' : 'microchip', >>> 'mpa1600' : 'microchip', >>> 'animeo_ip' : 'microchip', >>> 'aks-cdu' : 'microchip', >>> 'ethernut5' : 'microchip', >>> 'evk-pro3' : 'microchip', >>> 'pm9g45' : 'microchip', >>> 'ge86' : 'microchip', >>> 'bcm' : 'brcm', >> >> How about we use 'broadcom' here, to follow what arm64 does? I could >> rename arch/mips/boot/dts/brcm to arch/mips/boot/dts/broadcom for >> consistency, too? > > Okay, though if starting clean I'd somewhat prefer to use the vendor > prefix. I guess since arm and arm64 share dtsi files, they should > match. Sounds good to me, let's go with "brcm" then.
On 5/3/23 13:02, Arnd Bergmann wrote: > On Tue, May 2, 2023, at 21:40, Rob Herring wrote: >> On Tue, May 2, 2023 at 3:15 AM Arnd Bergmann <arnd@arndb.de> wrote: > ... > >> 'stm' : 'stm32', >> 'sti' : 'sti', >> 'st-pin' : 'sti', >> 'ste' : 'st-ericsson', >> 'spear' : 'spear', > > I would put all five of these into 'st'. The ux500 was developed > in st-ericsson, but last sold by st, and the other ones are all > original st products. Acked-by: Alexandre TORGUE <alexandre.torgue@st.com> thanks Alex > > Arnd > _______________________________________________ > Linux-stm32 mailing list > Linux-stm32@st-md-mailman.stormreply.com > https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
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.
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
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
On Tue, May 9, 2023 at 4:55 PM Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote: > > On Tue, May 02, 2023 at 02:40:19PM -0500, Rob Herring wrote: > [...] > > I've dusted off my script and made a branch[1] with the result. > > There's just a couple of fixes needed after the script is run (see the > > top commit). The cross arch includes are all fixed up by the script. > > dtbs_install maintains a flat install. I compared the number of .dtbs > > before and after to check the script. > > > > I think the only issue remaining is finalizing the mapping of > > platforms to subdirs. What I have currently is a mixture of SoC > > families and vendors. The most notable are all the Freescale/NXP > > platforms, pxa, socfpga, and stm32. It's not consistent with arm64 > > either. Once that's finalized, I still need to go update MAINTAINERS. > > > > Here's the current mapping: > > > > vendor_map = { > [...] > > 'aspeed' : 'aspeed', > > 'ast2' : 'aspeed', > > 'facebook' : 'aspeed', > > 'ibm' : 'aspeed', > > > 'openbmc' : 'aspeed', > > The openbmc flash layouts are currently only used by aspeed devicetrees, > but they don't really depend on any aspeed details. It would be possible > to reuse them in Nuvoton BMC devicetrees in the future, for example. > > In that sense, I think putting them in a separate "openbmc" directory > would be slightly better. Could be used on arm64 or riscv too at some point. We do some cross arch includes, but IMO it would be better to move to include/dt-bindings/ or somewhere outside of arch/. Other common things I didn't move. I could do that here too. I prefer to that the sub-directories are just chip vendors/families. Rob