On Mon, 2007-07-16 at 08:51 +0200, Robert Schwebel wrote: > On Sun, Jul 15, 2007 at 06:48:53AM +1000, Benjamin Herrenschmidt wrote: > > Your approach would work I suppose.... though it's a bit ugly. > > Speaking of uggly, I'm still wondering why this oftree stuff for powerpc > must be soooo complicated. If you come from the ARM-linux world like we > do, the whole powerpc BSP stuff looks like a completely overengineered > piece of code, introducing complexity where it isn't necessary. But it > may be that it's just me not knowing powerpc kernel requirements deeply > enough :) > > For most of the devices on for example the MPC5200B and MPC8260 I would > just model them as platform devices; there could be a simple > > oftree -> oftree-interpreter -> bunch of platform devices
As I wrote a couple of times already, it's a perfectly acceptable approach to have "constructors" (what you call oftree-interpreter) that generate platform devices from the OF tree. Since any struct device in the system can be associated with an OF device node, it's actually not that interesting anymore to use something such as of_platform_device or in general, subclasses of of_device unless this is a platform native bus (such as sbus on sparc, or ebus on power) that makes no sense to use without OF. One of the idea I have for the long term but didn't have time to implement is typically to have a bunch of generic constructors that register to match against device name/type/compatible triplets, and are called as part a boot time initial device-tree walk, generating the various linux devices on the fly. This could also generate PCI devices, thus replacing the separate walk path done by ppc64, but it could be used to generate any type of linux device, not necessarily OF-derivative ones, but platform devices too etc... I just haven't had time to work on that yet. You are welcome to beat me to it. Note that a lot of the complexity is mostly perceived complexity due to some of the stupid endless debates we've been having on this list. For things like interrupt mapping, for example, the OF tree is a very useful and very flexible representation that makes things a lot simpler on the kernel side when you start having multiple levels of cascaded interrupt controllers. > mapping. Is there a reason why there is sooo much interaction of the > platform code with the oftree? We usually have the situation that, if > something goes wrong, you have to change > > - the driver > - the platform code > - the oftree There should generally be no need to change the platform code. > and they often contain redundant information (like names of oftree > nodes, which change more often than some people's panties). 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. Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
