linux-kernel - Re: [PATCH] arm64: dts: qcs404: evb: Fix voltages for s5 and l3

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, 4 Feb 2019 08:03:37 -0800
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Niklas Cassel <niklas.cassel@...aro.org>,
        Jorge Ramirez <jorge.ramirez-ortiz@...aro.org>,
        Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Khasim Syed Mohammed <khasim.mohammed@...aro.org>
Subject: Re: [PATCH] arm64: dts: qcs404: evb: Fix voltages for s5 and l3

On Mon 04 Feb 02:43 PST 2019, Mark Brown wrote:

> On Tue, Jan 29, 2019 at 11:46:52PM +0100, Niklas Cassel wrote:
> 
> > Adding Mark Brown on CC.
> 
> It really helps if you ask a specific question when doing something like
> this rather than just have a big quoted mail - it makes it much easier
> to find what's relevant rather than trying to find things, especially
> when they're buried behind several layers of quoting.
> 
> > On Tue, Jan 29, 2019 at 10:58:47PM +0100, Jorge Ramirez wrote:
> > > On 1/26/19 00:29, Bjorn Andersson wrote:
> 
> > > the question is, should this property contain only hardware achievable
> > > values? or should drivers only request hardware achievable values? the
> > > way the constrains are implemented it has to be one of the two (I think
> > > the former would be more intuitive - ie if the dts
> > > regulator-min-microvolt is a valid value)
> 
> Drivers should not be coded with a specific regulator or board in mind
> and should just request whatever they need.  This will then be matched
> with whatever the board is actually able to deliver.  Similarly there is
> no requirement that machine constraints be written with specific
> reference to what the physical regulator on the board is able to do, for
> example the constraints will come from electrical engineering
> restrictions like the specifications of the parts connected to the
> regulator rather than from what the regulator can actually do so people
> should feel free to just write down the actual physical constraint and
> let the regulator API ensure that the constraint is met.

We have a regulator that is described as 1.05V in the schematics for the
board we're working on and we have the USB block wanting 1.05V on one of
its pins.  But the particular regulator works in steps of 8mV, and the
adjacent steps are 1.048V and 1.056V.

A) If we describe the min-microvolt = max-microvolt = 1.05V then the
regulator frameworks adjusts the min value to 1.056V, per the steps, and
fail as min > max.

B) The USB driver that we inherited was written to request min/max of
1.05V/1.05V, so pointing this to a regulator with min/max of e.g.
1.05V/1.06V we're outside the adjusted range of 1.056V/1.06V.


So the question is, should the board dts be written with
min/max-microvolt adjusted to match the hardware steps? Or could the
regulator framework be made to round down to the previous valid step
instead of up?

Regards,
Bjorn