linux-kernel - Re: [PATCH 1/1] regulator: Only enable disabled regulators on resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 3 Mar 2015 09:24:58 -0800
From:	Doug Anderson <dianders@...omium.org>
To:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
Cc:	Mark Brown <broonie@...nel.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] regulator: Only enable disabled regulators on resume

Javier,

On Mon, Mar 2, 2015 at 12:40 PM, Javier Martinez Canillas
<javier.martinez@...labora.co.uk> wrote:
> After leaving from system wide suspend state, regulator_suspend_finish()
> turn on regulators that may be turned off by regulator_suspend_prepare()
> but it tries to enable all regulators that have an enable count > 0 or
> that were marked as "always-on" regardless if those were disabled or not.
>
> Trying to enable an already enabled regulator may cause issues so is
> better to skip enabling regulators that were not disabled before suspend.
>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@...labora.co.uk>
> ---
>  drivers/regulator/core.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)

I've tested this and it also fixes the problem that my patch
(regulator: core: Fix enable GPIO reference counting -
https://patchwork.kernel.org/patch/5903071) fixes.

As I said in the other conversation I think both patches could land.
...but maybe change your commit message to something like:

The _regulator_do_enable() call ought to be a no-op when called on an
already-enabled regulator.  However, as an optimization
_regulator_enable() doesn't call _regulator_do_enable() on an already
enabled regulator.  That means we never test the case of calling
_regulator_do_enable() during normal usage and there may be hidden
bugs or warnings.  We have seen warnings issued by the tps65090 driver
and bugs when using the GPIO enable pin.

Let's match the same optimization that _regulator_enable() in
regulator_suspend_finish().  That may speed up suspend/resume and also
avoids exposing hidden bugs.

>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index f2452148c8da..8551400d57e4 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -3816,9 +3816,11 @@ int regulator_suspend_finish(void)
>         list_for_each_entry(rdev, &regulator_list, list) {
>                 mutex_lock(&rdev->mutex);
>                 if (rdev->use_count > 0  || rdev->constraints->always_on) {
> -                       error = _regulator_do_enable(rdev);
> -                       if (error)
> -                               ret = error;
> +                       if (!_regulator_is_enabled(rdev)) {

Looking at _regulator_enable() I see that _regulator_is_enabled()
could return an error.  Should we be checking?  Maybe we should have a
helper function called by both callers?

I have tested this on my system and it works.  Other than the error
check / updated commit message this looks good to me.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/