On Tue, Sep 10, 2013 at 11:44:05AM -0600, Stephen Warren wrote: > OK, so I believe you're saying that the case of a chip with just a > single power source, which absolutely must be present in HW for the chip > to be powered, isn't appropriate for regulator_get_optional(). Something > must always define a regulator for that power source, even if there is > no external SW control over that power source. Well, it really should be mandatory - personally I don't think it's sensible to add off-SoC chips without defining their regulators, it's more trouble than it's worth to have to add them later for all the time it takes to define the bindings. In IETF terms it's a should. > We either allow the regulator to be optional (since SW control over the > regulator is optional), or go back to every board file and DT and add a > dummy regulator in (which then breaks DT ABI, and even ignoring that is > a pain). The whole point of the way I'm changing the dummy support is to allow us to gracefully cope with errors here so there's no mandatory update even though strictly there should be one. > And note that when I say "optional" at the start of the previous > paragraph, I'm talking about probe-time regulator_get() operations and > DT content. Clearly as far as the rest of the driver is concerned, > something can always provide a dummy regulator so that e.g. > regulator_enable/disable() elsewhere always have something to operate > on. However, probe() either needs to call an API that automatically > provides such a dummy regulator, or open-code that itself. I'm still not > clear which option you think should be used. Clearly open coding this in every single driver is just not sane, you're immediately in the situation where every single driver has to implement the same thing at which point no driver ought to be doing it.
Attachment:
signature.asc
Description: Digital signature
