Re: Question on mpc52xx_common.c

["Grant Likely" <grant.likely@secretlab.ca>]

On Tue, Apr 8, 2008 at 1:45 PM, Robert Schwebel
<r.schwebel@pengutronix.de> wrote:
> On Tue, Apr 08, 2008 at 08:52:55AM -0600, Grant Likely wrote:
>  > It may be ideal, but I don't think it is realistic.  I'm now of the
>  > firm opinion that device trees and firmware are *never* perfect.
>  > Especially when the definition of perfect is a moving target.
>
>  Well observed; isn't this the prove of the assumption that the whole
>  device tree idea is not working? It is *always* inconsistent and it is
>  *maintenance hell* because out-of-tree ports do *always* breakt because
>  of string inconsistencies. We have just ported a 8260 board from 2.6.22
>  to 2.6.25 and it is almost 100% oftree porting. And you do not even have
>  a single point of a parser, because all this string parsing is
>  completely scattered all over the tree.

I disagree and that is not my point.  My point is that perfection is
neither obtainable or necessary.  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.  imperfect != bad.  I brought up a new 5200 board this week
which required zero kernel changes.  All I needed was a new dt to
describe the board.

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) it should be very stable and even if the
definition of ideal is changed, backwards compatibility must be
maintained.

>  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.  The moment you try to do
something more complex you either have the nightmare of bd_info or you
use a structured data format (like the device tree)

On another node, there are platforms where a device number is
unworkable.  For example, for Linux on an FPGA like the Xilinx Virtex,
there would need to be a new platform number every time the FPGA
bitstream was updated because it is effectively an entirely different
platform.

Finally, using a device number means you need to encode into the
kernel the exact layout of every platform it supports.  That adds up
to a lot of code in a real hurry; even if most of it is just
boilerplate instantiations.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.