On Mon, Aug 25, 2014 at 10:17 AM, Jonas Gorski <jogo@xxxxxxxxxxx> wrote: > On Sat, Aug 23, 2014 at 9:50 PM, Geert Uytterhoeven > <geert@xxxxxxxxxxxxxx> wrote: >> On Sat, Aug 23, 2014 at 8:31 AM, Olof Johansson <olof@xxxxxxxxx> wrote: >>>> > arch/arm/boot/dts/<vendor>/ >>>> > >>>> > Is this something we should do for the MIPS and update the other architectures >>>> > to follow that scheme? >>>> >>>> I recall reading that as well and that it would be adopted for ARM64, >>>> but that hasn't seemed to have happened. Perhaps Olof (CC'ed) will no >>>> more. >>> >>> Yeah, I highly recommend having a directory per vendor. We didn't on ARM, >>> and the amount of files in that directory is becoming pretty >>> insane. Moving to a subdirectory structure later gets messy which is >>> why we've been holding off on it. >> >> It would mean we can change our scripts to operate on "interesting" >> DTS files from >> >> do-something-with $(git grep -l $vendor, -- arch/arm/boot/dts) >> >> to >> >> do-something-with arch/arm/boot/dts/$vendor/* >> >> which is easier to type... > > Btw, do you mean chip-vendor or device-vendor with vendor? > Device-vendor could get a bit messy on the source part as the router > manufacturers tend to switch them quite often. E.g. d-link used arm, > mips and ubi32 chips from marvell, ubicom, broadcom, atheros, realtek > and ralink for their dir-615 router, happily switching back and forth. > There are 14 known different hardware revisions of it where the chip > differed from the previous one. There's probably no hard and fast rule that works perfectly for everything. Since the chip/soc generally defines most of the platform, I would say follow the chip vendor. A few "../other-vendor/" includes would be okay, but they should be the exception. 3rd party boards with common daughter cards come to mind here. Rob
