Question on mpc52xx_common.c

[Segher Boessenkool]

> 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