linux-kernel - Re: [PATCH] Regulator: add suspend-finish API for regulator core.

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, 8 Mar 2011 13:38:17 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	MyungJoo Ham <myungjoo.ham@...sung.com>
Cc:	linux-kernel@...r.kernel.org, Liam Girdwood <lrg@...mlogic.co.uk>,
	kyungmin.park@...sung.com, myungjoo.ham@...il.com
Subject: Re: [PATCH] Regulator: add suspend-finish API for regulator core.

On Tue, Mar 08, 2011 at 11:03:58AM +0900, MyungJoo Ham wrote:
> The regulator core had suspend-prepare that turns off the regulators
> when entering a system-wide suspend. However, it did not have
> suspend-finish that recovers the change made by suspend-prepare and
> depends on machine pm code or the regulator device or driver
> doing so.

This is a good idea, thanks for working on it.

Your commit message is sligtly inaccurate as this isn't what
suspend_prepare() is for, suspend_prepare() is for matching the suspend
mode configuration of regulators that support that with the suspend mode
Linux is using (RAM, disk and so on).  There is no need for this to
recover the pre-suspend state as hardware implementing suspend mode
configuration should be able to do so autonomously.

Of course not all hardware supports a distinct suspend mode and for
hardware that doesn't we should be doing pretty much this - it's a
bit of a hole in our regulator support at the minute.  It should really
be coupled with a soft suspend mode implementation which can put the
regulators into an appropriate state for suspend on the way down.

> +               if ((rdev->use_count > 0  || rdev->constraints->always_on) &&
> +                               rdev->desc->ops->enable) {
> +                       error = rdev->desc->ops->enable(rdev);
> +                       if (error)
> +                               ret = error;

We should probably also be turning off regulators that shouldn't be on -
a regulator may default to being enabled when we don't want it.
Thinking about it we can probably share most if not all of the code with
regulator_init_complete()...

Ideally we'd also restore voltages but that can always be added later.

> +       return ret;
> +}
> +EXPORT_SYMBOL_GPL(regulator_suspend_finish);

Hrm, I'd really expect the core to be arranging for this to happen
rather than exporting the function?  Though the sequencing so it gets
called at the right time might be a bit tricky and I've not actually
looked at the isues here.
--
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/