On Mon, Aug 25, 2014 at 8: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. I'm going to assume it means chip/SoC vendor. That would result in the following structure (I think): Octeon -> cavium/ Lantiq -> lantiq/ Netlogic -> netlogic/ (or should this now be brcm/?) SEAD-3 -> mti/ Ralink -> ralink/
