linux-kernel - Re: [PATCH v4] regulator: qcom-saw: Add support for SAW regulators

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:	Fri, 12 Feb 2016 23:03:00 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Stephen Boyd <sboyd@...eaurora.org>
Cc:	Georgi Djakov <georgi.djakov@...aro.org>,
	Lina Iyer <lina.iyer@...aro.org>, lgirdwood@...il.com,
	andy.gross@...aro.org, linux-kernel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v4] regulator: qcom-saw: Add support for SAW regulators

On Thu, Feb 11, 2016 at 04:17:55PM -0800, Stephen Boyd wrote:
> On 02/11, Georgi Djakov wrote:

> > 8064 uses SSBI instead of SPMI and we currently do not have any
> > existing regulator support upstream yet. So this driver is not
> > duplicating any existing regulator. We should decide whether to
> > keep this driver or to replace it with a new ssbi-regulator driver
> > and bindings instead, where we can avoid the split-bus fun at
> > least to some extent. Maybe the latter is the better option?

> Yes I think having an ssbi/spmi regulator driver may be a better
> approach. The SAW code can monitor the regulator for voltage
> changes with a notifier and then stick the restore voltage into
> the SAW registers. There's only one sticking point below.

So this is sounding like we want to drop this driver?

> modifies the SAW registers to set the voltage on the CPU that is
> using the regulator, thereby preventing the CPU from going idle
> or hitting suspend when the voltage is changed. If we were to use
> the SSBI/SPMI regulator driver we would need to do something
> similar so that the SPM is guaranteed to not be running during
> the voltage switch. So I guess schedule a work on the CPU that's
> affected by the voltage switch and hope that the CPU doesn't go
> offline during that time?

"Hope" doesn't sound like this is going to be a safe long term solution,
either something more integrated with the offline code that explicitly
blocks offlining (which I don't off the top of my head know if we can do
easily) or something where we start something on the CPU and then
explicitly handshake with it (but then what if the CPU has real work to
do?) seems better.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)