-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
Hi Mark - | This code looks dodgy, by the way - the client really should know if it Yeah. | 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. |> However, regulator_is_enabled() is giving a result for the actual state |> of the regulator, via a (ops->blah)() thing, but the _enable() and |> _disable() guys are looking first at the logical state they hold about |> if they enabled or disabled the regulator. | | 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 guess the answer is to solve them getting out of step, but it's a | | 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. |> funny feature that the regulator struct seems to be opaque for clients |> by design (fair enough) and there is no export to find logical state |> about their enable either. | | 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. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkkz/dUACgkQOjLpvpq7dMoFcACeOXpWzz34SFmjynIfDH/LlDzj h7IAnRyEDgyxVYhYrSWWhXhOMBkq1JDy =Lsv8 -----END PGP SIGNATURE-----
