Messages in this thread | | | Subject | Re: [RFC] [PATCH] Device Tree on ARM platform | From | Benjamin Herrenschmidt <> | Date | Thu, 28 May 2009 17:55:43 +1000 |
| |
On Thu, 2009-05-28 at 08:34 +0200, Wolfram Sang wrote: > > > OTOH, if it is appropriate for the device, then the binding can be defined to > > include things like page size and flags encoded explicitly in additional > > properties. > > ..., so I think a property like "page-size" could really be argumented for.
Most definitely. And it's in fact reasonably easy to define such bindings. And if somebody later decide do invent a fancier property called "page-data" that contains more structured informations, the driver can still fall back to using "page-size" when the later is not found. It's rarely needed but the technique works reasonably well.
> Actually, I am quite optimistic that there could be agreement on it. Maybe we > could also reuse the "read-only" property which is used for partitions. Still, > this discussion has to be done, and that is additional work for mainlining.
Well, it depends. You don't need to have defined all the bindings for all possible devices on the planet before adding to your architecture the core bits to have the ability to use device-trees :-)
However, it does make sense for a platform using it, to at least try to make sure that bindings for the devices it uses are in reasonable shape.
Again, no solution is ever perfect and whatever the technique is, somebody can make a mess of it. But my experience is that most of the time, those things come pretty easily out of common sense when talking about bindings for a -device-. Bindings for -busses- take a bit more thoughts, I agree.
> Also, this would be _another_ wrapper to collect data from the device tree and > pass it into platform_data. > I think it is difficult to maintain.
It's easier to have -one- piece of code taking data for device type X to create the platform data and than all platforms around having C code spread around that manufactures that platform data in 36 different ways.
So here, I disagree.
> If somebody > extends at24 and forgets about the of-wrapper, it may easily get broken.
No. If somebody adds new fields and not knowing about them doesn't break existing users, then only the first person to try to use the new functionality will discover the need for a new property and update the wrapper.
If somebody however changes the platform data in incompatible ways, that person is supposed to fix all users right ? So grep all platforms etc... and the wrapper will show up in that grep.
Also, it might be a lot easier to change just the wrapper don't you think ? :-)
> Plus,at least for me, coding always very similar stuff, feels like bloating the > kernel. I did it a few times now, and that made me really wonder if we can't > have a more generic solution to that problem. Sadly, I could neither come up > with anything useful :(
Well, the device-tree does avoid a -lot- of code duplication... you can see that easily when you look at our 4xx based platforms today vs. what they were in arch/ppc
Cheers, Ben.
| |