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]

Message-ID: <20190204104347.GD23441@sirena.org.uk>
Date:   Mon, 4 Feb 2019 11:43:47 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Niklas Cassel <niklas.cassel@...aro.org>
Cc:     Jorge Ramirez <jorge.ramirez-ortiz@...aro.org>,
        Bjorn Andersson <bjorn.andersson@...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 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.

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