On Tue, May 31, 2011 at 09:26:00AM +1000, Benjamin Herrenschmidt wrote: > The approach apple uses is interesting, where they essentially use > device-specific properties that contain a GPIO binding. For example, a > reset-gpio property, that points to the GPIO doing the reset, etc... This is exactly what I'm suggesting; it seems like the immediately obvious approach to take and it's certainly exactly what happens with the existing platform data code. > Or we could keep a gpio "map" and have a parallel property to name the > entries like I was originally thinking for the clocks. Honestly this would never even have occurred to me; how would that look and what would the indirection buy us (perhaps seeing how it looks would make that obvious)? > In any case, it's something that can reasonably easily be added on top > of the existing binding, and it would be much more productive Mark if > you actually proposed solutions rather than just opposing things :-) I'm really sorry you feel this way. All I'm doing here is looking at the existing platform data, looking at the device tree that's being proposed and saying "why can't we have something that's as usable as the platform data?" - I'd have thought that the suggestion was fairly obvious there. Just looking at the code it's completely unclear why we'd even be doing the approach in the original patch in the first place, Olaf's post was the first I knew about there being some existing convention here. One of the problems with the device tree style stuff to people who haven't used it and can't actually work on it (in my case I have no systems which can actually boot with a device tree) is that there's this whole bunch of rules that are already in place that we don't know about which people just refer us to - witness Olaf's response further up the thread, he said he queried a similar issue with a SD driver and was apparently just told that this is the way the device tree does things. I would anticipate that especially in the early stages of rollout where device tree is only available on a very limited selection of platforms you're going to get a bunch of such feedback from maintainers can and should review the code but are doing so purely based on looking at the code they're seeing. I've actually seen a bit of device tree stuff before but a lot of people won't have done so - if there's stuff people are querying you're going to have to explain things, even if they're well established device tree conventions. This is going to be one of the biggest challenges with rolling out device tree, both from the point of view of maintainers learning about how the device tree stuff should look and from the point of view of maintainers learning who to trust on device tree. There's a few people like you and Grant that I know are really familiar with this stuff but there's also going to be a whole raft of new people submitting device tree support and if something looks off maintainers are going to have to work out if it's due to some peculiar device tree idiom or if it's just an issue in the patch. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html