I disagree and that is not my point. My point is that perfection is
neither obtainable or necessary.
It's a nice goal though.
Many of the recently established
embedded guidelines are not "perfect" because they are counter to a
few of the OF recommended practices. However, they are consistent
within themselves, they work, and once established they are not going
to change.
Yeah. Which is good, even if the bindings themselves aren't
so good.
Now, if out-of-tree ports continue to break then we've got a problem
that needs to be fixed. Once a binding is established (which usually
takes a few kernel releases)
This is a big problem that is totally avoidable.
*Before* accepting any patches that use a new binding (including
patches to .dts files), that binding itself needs to be discussed.
This will be a lot less work than trying to see what's going on in
some platform/device code and/or some example device tree, and
spotting mistakes there. It might be a little more work upfront,
and it might seem like it would increase lead time, but as usual,
it's worth it.
Let's flat out refuse any patch series that uses a non-documented
binding.
it should be very stable and even if the
definition of ideal is changed, backwards compatibility must be
maintained.
Which is a good argument why getting it right the first time is
so important (as with all interfaces, nothing specific about
device trees here).
The ARM method of using just a device number is so much easier ...
Only if the assumption is made that very little data needs to be
shared between the kernel and the firmware.
...which means the kernel has to know *everything* about the hardware
setup and/or what settings the firmware established; i.e., the kernel
has to 100% replace the firmware. This can be nice for some use cases
(it's the route LinuxBIOS took originally), but it simply doesn't
scale, not in any dimension.
Segher
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
