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]

Date:   Mon, 3 Jan 2022 20:05:40 +0530
From:   "Satya Priya Kakitapalli (Temp)" <quic_c_skakit@...cinc.com>
To:     Mark Brown <broonie@...nel.org>,
        David Collins <quic_collinsd@...cinc.com>
CC:     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 12/11/2021 2:41 AM, Mark Brown wrote:
> 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.

This means Dynamic headroom control feature needs to be implemented. I 
need to explore more on this and gather info from team, Could we merge 
the present driver with "static headroom" for now? I'll do a follow up 
series to implement this feature.