linux-kernel - Re: [PATCH] regulator: rk808: Add support setting suspend voltage

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:	Wed, 8 Oct 2014 09:12:59 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	Chris Zhong <zyw@...k-chips.com>,
	Heiko Stübner <heiko@...ech.de>,
	linux-rockchip@...ts.infradead.org,
	Liam Girdwood <lgirdwood@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
Subject: Re: [PATCH] regulator: rk808: Add support setting suspend voltage

Mark,

On Wed, Oct 8, 2014 at 5:49 AM, Mark Brown <broonie@...nel.org> wrote:
>> One point of curiosity (maybe this is a question for Chanwoo and
>> Javier): I'd expect that if someone didn't explicitly setup a "suspend
>> voltage" that their voltage would just be left alone at suspend time.
>
> No, this is not the case.  The suspend mode settings are a completely
> different set of settings activated when the system goes into suspend
> with explicit hardware support.  If no configuration for this mode is
> provided then

I think maybe you missed finishing your sentence?

>> I believe that won't be the case for your driver.  The rk808 will (I
>> think) automatically transition to the "suspend voltage" settings for
>> ALL regulators at suspend time.  If you didn't explicitly set the
>> suspend voltage then you'll move to whatever the default voltage is,
>> right?
>
> As ever the hardware configuration won't be touched by the kernel unless
> it's explicitly told to do something.

I guess my point is that the kernel's inaction is actually causing
something unexpected to happen.  Robots can't let humans come to harm
by inaction any more than they can harm them by action.

Specifically I would expect that voltages would stay constant when the
rk808 "sleep" pin is asserted if I didn't explicitly say to disable
this regulator at sleep time and I didn't explicitly specify a voltage
at sleep time.  As Chris's patch stands right now this isn't the case.

To make it concrete, imagine that no "sleep voltage" was specified for
DCDC4 and it's setup to stay enabled during sleep.  Let's say that a
kernel driver makes a decision at runtime time to set this to 1.8V or
1.9V.

When the kernel driver sets it to 1.9V, it will go through
regulator_set_voltage_sel_regmap() which will set the BUCK4_ON_VSEL
register and we'll be at 1.9V.  Great, we're at 1.9V.  Now we're ready
to go to sleep.  I'd expect that the voltage would stay at 1.9V, but
it won't.  BUCK4_SLP_VSEL was never programmed so it's at whatever the
default is (1.8V) and we will transition there.

The above is a fictitious example since really we don't vary BUCK4 at
runtime in our system.  ...and really my concern only matters for
regulators that vary at runtime, so maybe we can ignore my comments.
To me, it does seem unexpected, though.

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