Regulators in suspend

[Andy Green]

-----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-----