How to add platform specific data to a of_device

Segher Boessenkool segher at kernel.crashing.org
Tue Jul 17 02:47:21 EST 2007


>> Well, they aren't supposed to :-) The problem at this point is  
>> more due
>> to the fact that for things that haven't been specified by  
>> official OF
>> bindings, people are going all over trying to define their own and
>> sometimes conflicting bindings and then changing them.
>
> I think it is a fundamental thing: the "we just have to wait long
> enough, until oftree definitions have settled" proposal just isn't
> right.

The big problem here is that lots of people got the _basic_
stuff wrong.  I feel that this is getting much better the
last few months though :-)

> It may be right for big irons, being well defined.

OF is being successfully used on many many more systems
than just "big iron"; and many of those do have really weird
quirks.  arch/powerpc also deals with many systems that don't
get their device trees quite right (*cough* powermac *cough*)
and that is doable just fine.  The quirks should be separated
more from the normal code though, in the Linux OF layer.

> But for the
> embedded processors, too less people are working on it, plus we  
> have too
> much things which could be defined.

For embedded, too often the whole bloody thing is dropped
onto the "bigger Linux community" after it has been developed
in-house for many many months.  And usually, lots of core
things are very wrong.  This is a problem with "embedded"
in general, nothing new for OF.

> Speaking of the MPC5200, look at how
> often device tree names change, e.g. for mpc5200 vs. mpc52xx vs.
> whatever. As long as things change, you have to keep the three  
> locations
> in sync manually, and that's bad.

No, you *do not* have to keep them in synch, that's part of
the beauty of the device tree definition.  Sure, you have to
make sure the consumer is at least as new as the producer,
unless people took pains to try to create wrong-way-around
compatibility.  Nothing new there.


Segher




More information about the Linuxppc-dev mailing list