linux-kernel - Re: [PATCH V4 1/6] dt-bindings: regulator: Add "regulator-min-dropout-voltage-microvolt"

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: <YbPCjbnH6cXQqy6S@sirena.org.uk>
Date:   Fri, 10 Dec 2021 21:11:41 +0000
From:   Mark Brown <broonie@...nel.org>
To:     David Collins <quic_collinsd@...cinc.com>
Cc:     "Satya Priya Kakitapalli (Temp)" <quic_c_skakit@...cinc.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>, swboyd@...omium.org,
        subbaram@...eaurora.org, Das Srinagesh <gurus@...eaurora.org>,
        linux-arm-msm@...r.kernel.org, Lee Jones <lee.jones@...aro.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V4 1/6] dt-bindings: regulator: Add
 "regulator-min-dropout-voltage-microvolt"

On Wed, Dec 08, 2021 at 04:56:48PM -0800, David Collins wrote:
> On 12/7/21 7:19 AM, Mark Brown wrote:
> > On Tue, Dec 07, 2021 at 08:36:11PM +0530, Satya Priya Kakitapalli (Temp) wrote:

> > that regulator.  We absolutely can and do expect this to be board
> > independent, it's a function of the design of the regulator.  Sharing
> > the input supply has no impact on this, the input voltage that the
> > regulator needs just get fed into the requiremnts on the supply voltage.

> The PM8008 LDOs are low noise LDOs intended to supply noise sensitive
> camera sensor hardware.  They can maintain output regulation with a
> fixed headroom voltage.  However, in order to guarantee high PSRR, the
> headroom voltage must be scaled according to the peak load expected from
> the each LDO on a given board.  Thus, we included support for a DT
> property to specify the headroom per LDO to meet noise requirements
> across boards.

Interesting...  how much extra headroom are we talking about here?  I'd
be unsurprised to see this usually just quoted as part of the standard
headroom requirement and this smells like the sort of thing that's going
to be frequently misused.  If the gains are something worth writing home
about I'd think we should consider if it's better to support this
dynamically at runtime based on load information and provide options for
configuring the peak load information through DT instead for static
configurations.  That would fit in with the stuff we have for managing
modes on DCDCs (which isn't really deployed but is there) and the API we
have for allowing client drivers to indicate their load requirements at
runtime that fits in with that.  That'd allow us to only boost the
headroom when it's really needed.

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