quoted

quoted

Not that there's anything wrong with your
reasoning.  Just seems like we're trying really hard to define
something
"correctly" when we control what's on both sides :).

Right now, and in your case, you do.  OTOH, the
goal is to have the DTS be a well-established
stable interface between the firmware/bootloader/
bootwrapper and the kernel; there is no room for
either side of that interface playing dirty tricks,
not on any board ;-)

Also, the DTS files in the kernel source tree should
server as a best-of-breed example for people doing
custom device trees for their own boards.  We better
whip them into good shape or we'll all look foolish...

Yeah, I know.  Ignore my earlier email.  I blame it on lack of sleep.

The only issue we might have in the future is if DT capable firmware 
for
these boards shows up and does something completely different.

Yeah, that's exactly the same problem as we would have
if we would code our device trees without trying to at
least create an informal binding for the nodes in question:
total chaos.

Hopefully that won't happen.

Hopefully, indeed.

If a third party constructs a board with some weird
device tree, then they probably have a big set of Linux
patches to go with that.  Now either they work with the
kernel community to get that integrated into mainline
(which means they need to do a lot of changes to the DTS
as well if it indeed is weird / wrong, so they better
start doing that *before* selling the boards); or they
can happily maintain their own kernel fork, like so many
companies already do.

I don't see a problem here :-)


Segher