>> 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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
