Question on mpc52xx_common.c

Segher Boessenkool segher at kernel.crashing.org
Wed Apr 9 07:51:54 EST 2008


> 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




More information about the Linuxppc-dev mailing list