On Mon, Aug 25, 2014 at 5:17 PM, Jonas Gorski [off-list ref] wrote:

On Sat, Aug 23, 2014 at 9:50 PM, Geert Uytterhoeven
[off-list ref] wrote:

quoted

On Sat, Aug 23, 2014 at 8:31 AM, Olof Johansson [off-list ref] wrote:

quoted

quoted

quoted

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.

That's indeed a good question, as you'll be having a *.dts for a device,
including a *.dtsi for an SoC.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html