On Wed, Jun 20, 2012 at 03:01:15PM -0600, Stephen Warren wrote: > On 06/20/2012 02:40 PM, Arnd Bergmann wrote: > > For a "compatible" property, I would expect two objects that have > > the same register-level interface but are responsible for different > > physical objects to have the same "compatible" values, but here > > you specifically need distinct "regulator-compatible" values. > I'd originally suggested "regulator-id" instead of > "regulator-compatible" in order to avoid any association with the > pre-existing "compatible" property. Mark didn't like that, although I > don't think I quite understood why. Like I said we already have names (and we have IDs inside the API as well) and it also seems better to make the "which thing is this?" property have the same name as the more generic "which thing is this?" property. I did mention the fact that drivers could read additional properties to further identify the regulator if they were so moved. Ideally we'd just be able to have either named nodes directly in the parent or be able to have arrays function as a hash, really this is trying to simulate a hash. > The problem is that dtc has no named constants. Using raw integers > instead of names would make the .dts file rather unreadable. The issue > is much more accute for regulators than say GPIOs or IRQs because > there's likely no relative order to the set of regulators defined by the > documentation, unlike for GPIOs/IRQs where the integer (often) is the > object's primary ID. Well, there are actually a lot of chips which do provide useful indexes - for example the wm831x devices just have a bunch of DCDCs and a bunch of LDOs which can usefully be referred to as DCDCn or LDOn. They will hopefully not need to use this interface. It's just that there's also a large class of devices we need to cater for which don't have any such regularity in their register map, this biding mechanism is for them.
Attachment:
signature.asc
Description: Digital signature
