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]

Message-ID: <56BC5FA7.5020108@linaro.org>
Date:	Thu, 11 Feb 2016 12:17:11 +0200
From:	Georgi Djakov <georgi.djakov@...aro.org>
To:	Stephen Boyd <sboyd@...eaurora.org>,
	Mark Brown <broonie@...nel.org>
Cc:	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 02/11/2016 12:46 AM, Stephen Boyd wrote:
> On 02/10, Mark Brown wrote:
>> On Wed, Feb 10, 2016 at 11:04:36AM -0800, Stephen Boyd wrote:
>>
[..]
>>> I'm not really excited about the binding we have here either.
>>> We're going to have two places in DT where we've created a
>>> regulator for the same physical regulator. One will be a child of
>>> the SAW node on the MMIO bus, and another will be a child of the
>>> PMIC on the SPMI/SSBI bus. In the end, they're both the same
>>> regulator, so any constraints on one node will need to be applied
>>> to the other node as well.
>>
>> Are you saying that this is a problem with the driver that just got
>> merged?  We got to v4 before I applied the driver...  My understanding
>> was that this is a driver for a new regulator type not a duplicate
>> interface for existing regulator.
> 
[..]
> 
> Now this is all pretty much useless hardware if all we care about
> is to set voltages from software. Obviously we could just use the
> SPMI regulator driver that we already have. It's written for the
> bus that the hardware is actually on and it works!
> 

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?

> The problem there is that the SAW register is also used during
> idle/suspend when software isn't running. The CPU power down
> sequence usually turns off the regulator, but it may also change
> the voltage to something lower, depending on how deep of
> idle/suspend we're trying to achieve. This is all done without
> software intervention. When the CPU wakes up due to some
> interrupt, the SPM runs the CPU power on sequence which takes
> whatever is in the SAW register and sends it off to the PMIC to
> restore the CPU voltage. Again, this is all hardware doing this.

This might be a problem. I guess we can't change this hardware
behaviour?

Anyway, thanks for the detailed feedback. This is very helpful,
as I have very limited information on this hardware.

BR,
Georgi