On 08/27/2014 11:30 AM, Andrew Bresticker wrote:
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/
To match the state of the art naming we have in other MIPS related
directories, it should probably be "cavium-octeon/" (See
arch/mips/cavium-octeon, and arch/mips/include/asm/mach-cavium-octeon)
David Daney
