On Mon, Dec 01, 2008 at 03:08:10PM +0000, Andy Green wrote: > | has enabled the regulator or not and shouldn't be relying on the > | physical state of the regulator at all if it's not enabled it.
> That breaks down when we inherit dynamic situation from bootloader for > example. There needs to be a way to adapt to the situation at the > physical regulator, maybe it should happen by default since there is a > way to sense it. Right, that's the main use case I mentioned for the existing is_enabled() - bootstrapping. The driver can look at the state when it's starting up and set itself up appropriately. That would include enabling the regulator if desired. > | Right, the regulator may be shared, may be forced on by the machine > | constraints or may be left powered on at startup so the soft and hard > | states may diverge. > It seems an API to get an elected consumer to adopt the state of the > real regulator might not be a bad thing. I'm not sure what you anticipate this doing? You can force the state of the regulator at startup via the machine constraints. > | The real fix is for the driver to know if it wants the regulator to be > | enabled and track that. > The situation can be the driver actually wants to adopt inherited > regulator physical state. The "dodgy" code is trying to do that. It's never keeping track of the state it wants at all, it's attempting to force a particular physical state without reference to the logical state. If it were keeping track of the state it wants it would only do so at startup. > | There's not been any demand before, TBH - the main use case for the > | existing API is bootstrapping. > It seems funny the "query" and the "set" operations in this API don't > involve the same state. Yes, that's true for enabled.
