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:   Tue, 29 Jan 2019 23:46:52 +0100
From:   Niklas Cassel <niklas.cassel@...aro.org>
To:     Jorge Ramirez <jorge.ramirez-ortiz@...aro.org>
Cc:     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>,
        broonie@...nel.org
Subject: Re: [PATCH] arm64: dts: qcs404: evb: Fix voltages for s5 and l3

Adding Mark Brown on CC.

On Tue, Jan 29, 2019 at 10:58:47PM +0100, Jorge Ramirez wrote:
> On 1/26/19 00:29, Bjorn Andersson wrote:
> > PMS405 S5 was upstreamed without a voltage and PMS405 L3 is outside the
> > acceptable range, causing PCIe to fail. Fix these.
> > 
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> > ---
> >  arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
> > index 579ddaf4f5fa..072061aa1b79 100644
> > --- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
> > @@ -72,8 +72,8 @@
> >  		};
> >  
> >  		vreg_s5_1p35: s5 {
> > -			regulator-min-microvolt = <>;
> > -			regulator-max-microvolt = <>;
> > +			regulator-min-microvolt = <1352000>;
> > +			regulator-max-microvolt = <1352000>;
> >  		};
> >  
> >  		vreg_l1_1p3: l1 {
> > @@ -87,7 +87,7 @@
> >  		};
> >  
> >  		vreg_l3_1p05: l3 {
> > -			regulator-min-microvolt = <976000>;
> > +			regulator-min-microvolt = <1050000>;
> 
> 
> the linear range for this regulator is
>  - REGULATOR_LINEAR_RANGE(312000, 0, 127, 8000),
> 
> meaning that 1050000 is actually not a valid selectable value (ie, after
> applying the above constrains 1056000 would be selected instead)
> 
> In order for a driver to be able to successfully request min = 1050000,
> regulator-min-microvolt should be set to 1048000 (and 1056000 would be
> applied)
> 
> 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)
> 
> >  			regulator-max-microvolt = <1160000>;
> >  		};
> >  
> > 
>