linux-kernel - Re: [PATCH 1/2] regulator: add QCOM RPMh regulator driver

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:   Thu, 17 May 2018 15:09:48 +0900
From:   Mark Brown <broonie@...nel.org>
To:     David Collins <collinsd@...eaurora.org>
Cc:     Stephen Boyd <swboyd@...omium.org>, lgirdwood@...il.com,
        mark.rutland@....com, robh+dt@...nel.org,
        linux-arm-msm@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, rnayak@...eaurora.org,
        ilina@...eaurora.org
Subject: Re: [PATCH 1/2] regulator: add QCOM RPMh regulator driver

On Tue, Apr 24, 2018 at 01:46:21PM -0700, David Collins wrote:
> On 04/24/2018 10:41 AM, Mark Brown wrote:

> > If the hardware has full knowledge of all these constraints and enforces
> > them transparently then why does the kernel care that it's doing that?
> > Doesn't it defeat the point of it doing all this stuff if we have to
> > know about it?

> The RPMh hardware is aware of the parent-child connections between
> regulators as well as minimum headroom to ensure stable LDO voltage output
> for subregulated LDOs.  The intention of having the headroom be a
> configurable property for processors is to support usecases in which
> subregulated LDO loads are particularly sensitive to noise and require
> additional headroom.  Such usecases are board dependent and beyond the
> baseline configurations set in RPMh hardware.

So the hardware implementation is some hard coding stuff that doesn't
really adequately reflect reality?  This seems unfortunate.  However do
we really need to tell the hardware about the fact that we're adding
extra headroom - are there actual interactions with non-Linux things
here?

> >> XOB managed regulators physically cannot change voltage.  Therefore, do
> >> you agree that it is reasonable to use fixed_uV for them?  Note that I
> >> removed init_data->constraints.apply_uV manipulation in version 2 of this
> >> patch.

> > If these regulators can't change voltage then surely we know what
> > voltage they have without needing it to be specified in DT?

> In the case of XOB managed LDO regulators, the LDOs physically can be
> configured to different voltages by the bootloader.  However, the RPMh
> interface provides no mechanism for the application processor to read or
> change that voltage.  Therefore, we need a way to specify such voltages in
> a board specific (as opposed to driver specific) manner (i.e. device tree).

Is the kernel somehow prevented from varying these voltages?

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