And then you don't need this file at all. Just add a
"amcc,canyonlands" string to your root node compatible property.
No! Don't do this because it is not true!
If the board actually _is_ compatible to the canyonlands board (it
only _adds_ stuff, doesn't change things or takes away things), it
is perfectly valid to declare it compatible, since it _is_.
In my opinion, for the root compatible value, it is also okay to
declare a board compatible if it is only "largely" compatible,
just has some little differences -- esp. if you're declaring a
board to be compatible to some reference design. This does of
course have downsides as well.
Meh. You're splitting hairs. It _is_ true from a kernel perspective.
That doesn't matter. The device tree describes the hardware, it doesn't
matter what the Linux kernel does. For one thing, the kernel isn't
necessarily the only OS (or other client) to run with this DTS; also,
the kernel is a moving target, while the DTS can be burned into ROM.
Instead, add your board name to canyonlands.c in canyonlands_probe().
It's not the most scalable solution, but it keeps you from lying about
your hardware in the .dts file.
That could also be done. Frankly though, if you look at the existing
board.c files in there now, none of them are special. The device tree
really provides the differences these days, not the C code.
Yes. It would be more scalable if the platform probe code checks
the device tree for the features it expects (certain CPU, certain
interrupt controller, certain chipsets / bridges), instead of it
checking the root "compatible" property.
I'm this
|| close to just killing them all and doing a 4xx_board.c file that
does the right thing based on the few boards that have differences.
Oh, the kernel code even considers these things to be different
platforms? Insane :-)
Segher
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
