-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
|> | 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. Yes Balaji told about it. But actually I was talking about the case below again. |> | 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 some more "dodgy" code in probe() for this. Anyway I'll replace it with the boot_on attribute thing... for bt case it's okay to force it off and then we at least start on a consistent footing. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkk0CUAACgkQOjLpvpq7dMqrwACglS9b15N01xG9n3HcbaPFb28k llMAnjYRxtyPke/ZS92f4ZM6sAiD3P0F =LX+L -----END PGP SIGNATURE-----
