Regulators in suspend

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi -

I noticed something about the regulator stuff last night when dealing
with suspend on the pm_bt driver.

We have this kind of construct

		if (on) {
			if (!regulator_is_enabled(bt_data->regulator))
				regulator_enable(bt_data->regulator);
		} else {
			if (regulator_is_enabled(bt_data->regulator))
				regulator_disable(bt_data->regulator);
		}

because the regulator stuff only wants to hear disable on enabled
regulator and vice versa.

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.

On probe and resume at the moment these two things are out of step, the
regulator defaults to up on Qi it seems and they are wrong on resume too
at the moment, blowing WARN_ON() stacktraces.

I guess the answer is to solve them getting out of step, but it's a
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.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkzzBkACgkQOjLpvpq7dMosaQCfXeI1rRP19T0BXP9ol8zrVUF2
2vgAn0UOWNr11aYGOgqIeV6P9AI3ML8D
=1f85
-----END PGP SIGNATURE-----