linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
  • * Re: [RFC PATCH 0/1] Categorize ARM dts directory
           [not found] <20220328000915.15041-1-ansuelsmth@gmail.com>
           [not found] ` <20220328000915.15041-2-ansuelsmth@gmail.com>
    @ 2022-03-28  8:55 ` Daniel Palmer
      2022-03-29  7:53   ` Tony Lindgren
      2022-03-29  8:50   ` Nicolas Ferre
      2022-03-28 13:21 ` Jonathan Neuschäfer
      2022-03-29 13:20 ` Krzysztof Kozlowski
      3 siblings, 2 replies; 66+ messages in thread
    From: Daniel Palmer @ 2022-03-28  8:55 UTC (permalink / raw)
      To: Ansuel Smith
      Cc: Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, DTML,
    	Linux Kernel Mailing List, linux-actions, linux-sunxi, linux-omap,
    	linux-amlogic, linux-arm-kernel, linux-aspeed, linux-rpi-kernel,
    	chrome-platform, linux-renesas-soc, linux-samsung-soc,
    	linux-stm32, kernel, linux-mediatek, openbmc, linux-tegra,
    	linux-oxnas, linux-arm-msm, linux-unisoc, linux-rockchip,
    	linux-realtek-soc
    
    Hi Ansuel
    
    On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <ansuelsmth@gmail.com> wrote:
    >
    > Hi,
    > as the title say, the intention of this ""series"" is to finally categorize
    > the ARM dts directory in subdirectory for each oem.
    
    While I agree with this change and think it's for the good (browsing
    the ARM dts directory at the moment is frustrating..) I think
    buildroot and others need to be told about this as it'll potentially
    break their kernel build scripting for ARM and probably messes up the
    configs they have for existing boards.
    
    >  arch/arm/boot/dts/mstart/Makefile             |   10 +
    >  .../mstar-infinity-breadbee-common.dtsi       |    0
    >  .../mstar-infinity-msc313-breadbee_crust.dts  |    0
    >  .../{ => mstart}/mstar-infinity-msc313.dtsi   |    0
    >  .../boot/dts/{ => mstart}/mstar-infinity.dtsi |    0
    >  .../mstar-infinity2m-ssd201-som2d01.dtsi      |    0
    >  ...nfinity2m-ssd202d-100ask-dongshanpione.dts |    0
    >  .../mstar-infinity2m-ssd202d-miyoo-mini.dts   |    0
    >  .../mstar-infinity2m-ssd202d-ssd201htv2.dts   |    0
    >  .../mstar-infinity2m-ssd202d-unitv2.dts       |    0
    >  ...sd202d-wirelesstag-ido-sbc2d06-v1b-22w.dts |    0
    >  ...ity2m-ssd202d-wirelesstag-ido-som2d01.dtsi |    0
    >  .../mstar-infinity2m-ssd202d.dtsi             |    0
    >  .../mstar-infinity2m-ssd20xd.dtsi             |    0
    >  .../dts/{ => mstart}/mstar-infinity2m.dtsi    |    0
    >  .../mstar-infinity3-msc313e-breadbee.dts      |    0
    >  .../{ => mstart}/mstar-infinity3-msc313e.dtsi |    0
    >  .../dts/{ => mstart}/mstar-infinity3.dtsi     |    0
    >  .../mstar-mercury5-ssc8336n-midrived08.dts    |    0
    >  .../{ => mstart}/mstar-mercury5-ssc8336n.dtsi |    0
    >  .../boot/dts/{ => mstart}/mstar-mercury5.dtsi |    0
    >  arch/arm/boot/dts/{ => mstart}/mstar-v7.dtsi  |    0
    
    s/mstart/mstar/
    
    Cheers,
    
    Daniel
    
    _______________________________________________
    linux-arm-kernel mailing list
    linux-arm-kernel@lists.infradead.org
    http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
    
    ^ permalink raw reply	[flat|nested] 66+ messages in thread
  • * Re: [RFC PATCH 0/1] Categorize ARM dts directory
           [not found] <20220328000915.15041-1-ansuelsmth@gmail.com>
           [not found] ` <20220328000915.15041-2-ansuelsmth@gmail.com>
      2022-03-28  8:55 ` [RFC PATCH 0/1] Categorize ARM dts directory Daniel Palmer
    @ 2022-03-28 13:21 ` Jonathan Neuschäfer
      2022-03-28 13:27   ` Ansuel Smith
                         ` (3 more replies)
      2022-03-29 13:20 ` Krzysztof Kozlowski
      3 siblings, 4 replies; 66+ messages in thread
    From: Jonathan Neuschäfer @ 2022-03-28 13:21 UTC (permalink / raw)
      To: Ansuel Smith
      Cc: Rob Herring, Krzysztof Kozlowski, linux-arm-kernel, devicetree,
    	linux-kernel, linux-actions, linux-sunxi, linux-omap,
    	linux-amlogic, linux-arm-kernel, linux-aspeed, linux-rpi-kernel,
    	chrome-platform, linux-renesas-soc, linux-samsung-soc,
    	linux-stm32, kernel, linux-mediatek, openbmc, linux-tegra,
    	linux-oxnas, linux-arm-msm, linux-unisoc, linux-rockchip,
    	linux-realtek-soc
    
    
    [-- Attachment #1.1: Type: text/plain, Size: 2634 bytes --]
    
    On Mon, Mar 28, 2022 at 02:09:14AM +0200, Ansuel Smith wrote:
    > Hi,
    > as the title say, the intention of this ""series"" is to finally categorize
    > the ARM dts directory in subdirectory for each oem.
    [...]
    > [1] https://gist.github.com/Ansuel/47c49925ee7ef4b1dd035afc74679ab5
    > [2] https://gist.github.com/Ansuel/19f61f1e583c49407ce35c10e770fbe0
    
    Nice idea, thank you!
    
    A few notes on categorization below.
    
    
    >  create mode 100644 arch/arm/boot/dts/broadcom/Makefile
    >  rename arch/arm/boot/dts/{ => broadcom}/bcm-cygnus-clock.dtsi (100%)
    
    Or maybe bcm instead of broadcom. Not sure which is preferred by
    Broadcom people.
    
    >  create mode 100644 arch/arm/boot/dts/dove/Makefile
    >  rename arch/arm/boot/dts/{ => dove}/dove-cm-a510.dtsi (100%)
    
    Arguably part of Marvell.
    
    >  create mode 100644 arch/arm/boot/dts/edac/Makefile
    >  rename arch/arm/boot/dts/{ => edac}/ecx-2000.dts (100%)
    >  rename arch/arm/boot/dts/{ => edac}/ecx-common.dtsi (100%)
    >  rename arch/arm/boot/dts/{ => edac}/highbank.dts (100%)
    
    Why edac?
    The most obvious name I can see here is calxeda.
    
    >  create mode 100644 arch/arm/boot/dts/freescale/Makefile
    
    Freescale has been part of NXP for a while, so it might make sense to
    merge the freescale and nxp directories. I can't speak for
    NXP-the-company, so that's just my view as a bystander.
    
    >  create mode 100644 arch/arm/boot/dts/kirkwood/Makefile
    
    The Kirkwood family should probably be sorted into Marvell.
    
    >  create mode 100644 arch/arm/boot/dts/layerscape/Makefile
    >  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-moxa-uc-8410a.dts (100%)
    >  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-qds.dts (100%)
    >  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-tsn.dts (100%)
    >  rename arch/arm/boot/dts/{ => layerscape}/ls1021a-twr.dts (100%)
    >  rename arch/arm/boot/dts/{ => layerscape}/ls1021a.dtsi (100%)
    
    The Layerscape family is part of Freescale/NXP.
    
    >  create mode 120000 arch/arm/boot/dts/nxp/armv7-m.dtsi
    
    armv7-m.dtsi is a bit confusing, because it contains a few devices at
    fixed addresses, so it looks vendor-specific at a first glance into the
    file. However, if it is actually as vendor-neutral as the name implies,
    I think it should live dts/ directly, rather than in vendor
    subdirectories.
    
    >  rename arch/arm/boot/dts/{ => nxp}/lpc18xx.dtsi (100%)
    
    Here we have the NXP LPCxxxx family, which is AFAIK unrelated to the
    i.MX family (and thus the bulk of the Freescale legacy).
    
    >  create mode 100644 arch/arm/boot/dts/vybrid/Makefile
    
    Vybrid is another chip family of NXP, with a good deal of Freescale
    legacy in it as evidenced by the "fsl," prefix in the devicetrees.
    
    
    
    Thanks,
    Jonathan
    
    [-- Attachment #1.2: signature.asc --]
    [-- Type: application/pgp-signature, Size: 833 bytes --]
    
    [-- Attachment #2: Type: text/plain, Size: 176 bytes --]
    
    _______________________________________________
    linux-arm-kernel mailing list
    linux-arm-kernel@lists.infradead.org
    http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
    
    ^ permalink raw reply	[flat|nested] 66+ messages in thread
  • * Re: [RFC PATCH 0/1] Categorize ARM dts directory
           [not found] <20220328000915.15041-1-ansuelsmth@gmail.com>
                       ` (2 preceding siblings ...)
      2022-03-28 13:21 ` Jonathan Neuschäfer
    @ 2022-03-29 13:20 ` Krzysztof Kozlowski
      2022-03-29  4:56   ` Ansuel Smith
      3 siblings, 1 reply; 66+ messages in thread
    From: Krzysztof Kozlowski @ 2022-03-29 13:20 UTC (permalink / raw)
      To: Ansuel Smith, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel,
    	devicetree, linux-kernel, linux-actions, linux-sunxi, linux-omap,
    	linux-amlogic, linux-arm-kernel, linux-aspeed, linux-rpi-kernel,
    	chrome-platform, linux-renesas-soc, linux-samsung-soc,
    	linux-stm32, kernel, linux-mediatek, openbmc, linux-tegra,
    	linux-oxnas, linux-arm-msm, linux-unisoc, linux-rockchip,
    	linux-realtek-soc
      Cc: Arnd Bergmann, Olof Johansson
    
    On 28/03/2022 02:09, Ansuel Smith wrote:
    > Hi,
    > as the title say, the intention of this ""series"" is to finally categorize
    > the ARM dts directory in subdirectory for each oem.
    > 
    > The main reason for this is that it became unpractical to handle 2600
    > dts files and try to even understand/edit/check the situation for a
    > specific target.
    > 
    > In arm64 we already have this kind of separation and I honestly think
    > that this was never proposed for ARM due to the fact that there are
    > 2600+ files to sort and the fact that it will be a mess to merge this
    > entirely but IMHO with a little bit of effort we can finally solve this
    > problem and have a well organized directory just like arm64.
    > 
    > Some prerequisite on how this work was done:
    > - This comes entirely from a python script created by me for the task.
    >   linked here [1]
    > - I had to manually categorize all the different arch in the makefile
    >   based on the oem. I searched every arch on the internet trying to
    >   understand the correct oem. I hope they are correct but I would love
    >   some comments about them.
    > - This current ""series"" is all squashed in one big commit to better
    >   receive comments for this. The final version ideally would have all
    >   changes in separate commits. The script can already do this, it's just
    >   commented.
    > 
    > Here is a list of some discoveries while doing all the sorting.
    > These are totally additional reason why we need this.
    > 
    > While creating the script I discovered some funny things:
    > - We have orphan dts! There are dts that are never compiled and are
    >   there just for reference. We would never have noticed this without this
    >   change and probably nobody noticed it. They are currently all listed
    >   in the python script.
    > - We have dtsi shared across different oem. My current solution for them
    >   is: NOT SORT THEM and leave them in the generic directory and create a
    >   link in each oem dts that points to these dtsi. This is to try in
    >   every way possible to skip any additional changes to the dts.
    >   Current dtsi that suffers from this are only 3. (listed in the script)
    > - arm64 dts and dtsi reference ARM dts. Obviously this change would cause
    >   broken include for these special dtsi. The script creates a dependency
    >   table of the entire arm64 directory and fix every broken dependency
    >   (hoping they all use a sane include logic... regex is used to parse
    >   all the different dependency)
    > 
    > So in short the script does the following steps:
    > 1. Enumerate all the action to do... (dts to move, scan dependency for
    >    the dts...)
    > 2. Generate the arm64 dependency
    > 3. Creates the Makefile
    > 4. Generate the Makefiles for the current oem
    > 5. Move all the related dts and dtsi for the current oem
    > 6. Check broken dependency and fix them by editing the dts and writing
    >    the correct include (or fix any symbolic link)
    > 
    > This is an output that describes all the things done by the script [2]
    > 
    > I really hope I didn't commit any logic mistake in the script but most
    > of the work should be done.
    > 
    
    +Cc Arnd and Olof,
    
    Ansuel,
    Thanks for you patch. Please cc the SoC maintainers in such submissions.
    It seems that you got some quite nice discussion, but still the core
    folks are not Cced, so no one would be able to take your patch...
    
    I am pretty sure we were discussing such split idea in the past and it
    did not get traction, but I cannot recall the exact discussion.
    
    To me the idea is good but will cause huge `git am` conflicts.
    Cherry-picks, backports and merges should nicely detect path renames,
    but git am (and b4 am) I think cannot.
    
    Best regards,
    Krzysztof
    
    _______________________________________________
    linux-arm-kernel mailing list
    linux-arm-kernel@lists.infradead.org
    http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
    
    ^ permalink raw reply	[flat|nested] 66+ messages in thread

  • end of thread, other threads:[~2023-06-08 20:34 UTC | newest]
    
    Thread overview: 66+ messages (download: mbox.gz follow: Atom feed
    -- links below jump to the message on this page --
         [not found] <20220328000915.15041-1-ansuelsmth@gmail.com>
         [not found] ` <20220328000915.15041-2-ansuelsmth@gmail.com>
    2022-03-28  7:57   ` [PATCH RFC 1/1] ARM/arm64: categorize dts in arm dir and fix dependency in arm64 Geert Uytterhoeven
    2022-03-28  8:28   ` [RFC PATCH " Jesper Nilsson
    2022-03-28 11:55     ` Ansuel Smith
    2022-03-28  9:09   ` [Linux-stm32] " Patrice CHOTARD
    2022-03-28  9:20     ` Patrice CHOTARD
    2022-03-28 11:59       ` Ansuel Smith
    2022-03-28 12:11         ` Patrice CHOTARD
    2022-03-28 10:47   ` Matthias Brugger
    2022-03-28 11:54     ` Ansuel Smith
    2022-03-28  8:55 ` [RFC PATCH 0/1] Categorize ARM dts directory Daniel Palmer
    2022-03-29  7:53   ` Tony Lindgren
    2022-03-29  8:32     ` Andrew Jeffery
    2022-03-29  9:04     ` Geert Uytterhoeven
    2022-03-29  9:54       ` Tony Lindgren
    2022-03-29 10:06         ` Matthias Brugger
    2022-03-29  8:50   ` Nicolas Ferre
    2023-04-25 16:21     ` Robin Murphy
    2022-03-28 13:21 ` Jonathan Neuschäfer
    2022-03-28 13:27   ` Ansuel Smith
    2022-03-28 13:35     ` Jonathan Neuschäfer
    2022-03-28 13:50   ` H. Nikolaus Schaller
    2022-03-29  0:23     ` Andrew Jeffery
    2022-03-28 14:00   ` (EXT) " Alexander Stein
    2022-03-29  9:19   ` Alexandre Belloni
    2022-03-29 13:20 ` Krzysztof Kozlowski
    2022-03-29  4:56   ` Ansuel Smith
    2023-04-24 22:10     ` Rob Herring
    2023-04-24 22:23       ` Ansuel Smith
    2023-04-27  7:34         ` Matthias Brugger
    2023-04-25  7:27       ` Geert Uytterhoeven
    2023-04-25 15:57         ` Rob Herring
    2023-04-27  7:37           ` Matthias Brugger
    2023-04-27  7:46             ` Geert Uytterhoeven
    2023-04-27  7:48               ` Tony Lindgren
    2023-05-02  8:15           ` Arnd Bergmann
    2023-05-02 19:40             ` Rob Herring
    2023-05-02 20:02               ` Krzysztof Kozlowski
    2023-05-03  1:19                 ` Shawn Guo
    2023-05-03 10:43                   ` Arnd Bergmann
    2023-05-02 21:18               ` Linus Walleij
    2023-05-02 21:27                 ` Rob Herring
    2023-05-02 22:01               ` Christian Hewitt
    2023-05-03 10:42                 ` Neil Armstrong
    2023-05-02 22:52               ` Dmitry Baryshkov
    2023-05-03  1:17                 ` Rob Herring
    2023-05-03 10:38                   ` Arnd Bergmann
    2023-05-03 12:13                     ` Dmitry Baryshkov
    2023-05-03 12:18                       ` Arnd Bergmann
    2023-05-03 13:16                         ` Rob Herring
    2023-05-03 20:37                           ` Arnd Bergmann
    2023-05-03 20:39                             ` Linus Walleij
    2023-05-03 22:22                             ` Rob Herring
    2023-05-02 23:02               ` Florian Fainelli
    2023-05-03  1:04                 ` Rob Herring
    2023-05-03 22:29                   ` Florian Fainelli
    2023-05-03  5:57               ` Tony Lindgren
    2023-05-03  8:56               ` Geert Uytterhoeven
    2023-05-03 11:02               ` Arnd Bergmann
    2023-05-03 13:08                 ` Rob Herring
    2023-05-03 20:25                 ` Linus Walleij
    2023-05-04  7:09                 ` [Linux-stm32] " Alexandre TORGUE
    2023-05-03 12:01               ` Jesper Nilsson
    2023-05-04 10:11               ` Russell King (Oracle)
    2023-05-04 11:44                 ` Arnd Bergmann
         [not found]               ` <ZFrPJQdwoxqFpzUO@probook>
    2023-06-08 20:33                 ` Rob Herring
    2023-04-25  8:00       ` Krzysztof Kozlowski
    

    This is a public inbox, see mirroring instructions
    for how to clone and mirror all data and code used for this inbox;
    as well as URLs for NNTP newsgroup(s).