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