linux-kernel - Re: [PATCH v2 3/3] arm64: dts: qcom: sa8295p-adp: Add max20411 on i2c12

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] [day] [month] [year] [list]

Message-ID: <20230130035742.GB464800@hu-bjorande-lv.qualcomm.com>
Date:   Sun, 29 Jan 2023 19:57:42 -0800
From:   Bjorn Andersson <quic_bjorande@...cinc.com>
To:     Andrew Halaney <ahalaney@...hat.com>
CC:     Konrad Dybcio <konrad.dybcio@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] arm64: dts: qcom: sa8295p-adp: Add max20411 on
 i2c12

On Thu, Jan 26, 2023 at 05:43:54PM -0600, Andrew Halaney wrote:
> On Fri, Jan 27, 2023 at 12:35:37AM +0100, Konrad Dybcio wrote:
> > 
> > 
> > On 26.01.2023 23:54, Andrew Halaney wrote:
> > > On Tue, Jan 24, 2023 at 10:44:40AM -0800, Bjorn Andersson wrote:
> > >> From: Bjorn Andersson <bjorn.andersson@...aro.org>
> > >>
> > >> The SA8295P ADP has a Maxim max20411 step-down converter on i2c12.
> > >>
> > >> Signed-off-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> > >> Signed-off-by: Bjorn Andersson <quic_bjorande@...cinc.com>
> > >> ---
> > >>
> > >> Changes since v1:
> > >> - i2c node had changed name
> > >>
> > >>  arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 41 ++++++++++++++++++++++++
> > >>  1 file changed, 41 insertions(+)
> > > 
> > > I realized today this has to do with the comment over at:
> > > 
> > >     https://lore.kernel.org/all/30166208-ba9d-e6e6-1cd2-807a80536052@quicinc.com/
> > > 
> > > and I just didn't realize that the schematic I've started looking at
> > > black boxes the SOM/SIP which holds this... darn I thought I could see
> > > more than I could :(
> > > 
> > > I took a similiar patch for a spin on sa8540p-ride (which I'll later
> > > submit), and things worked fine (I'm not really consuming the output of
> > > the regulator mind you).
> > > 
> > > Downstream devicetree indicates all of this looks ok except for possibly
> > > the below comment:
> > > 
> > >>
> > >> diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> > >> index bb4270e8f551..642000d95812 100644
> > >> --- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> > >> +++ b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> > >> @@ -266,6 +266,27 @@ &dispcc1 {
> > >>  	status = "okay";
> > >>  };
> > >>  
> > >> +&i2c12 {
> > >> +	pinctrl-names = "default";
> > >> +	pinctrl-0 = <&i2c12_state>;
> > >> +
> > >> +	status = "okay";
> > >> +
> > >> +	vdd_gfx: regulator@39 {
> > >> +		compatible = "maxim,max20411";
> > >> +		reg = <0x39>;
> > >> +
> > >> +		regulator-name = "vdd_gfx";
> > >> +		regulator-min-microvolt = <800000>;
> > > 
> > > Is there a reason you chose this instead of the 500000 I see downstream?
> > > 
> > >> +		regulator-max-microvolt = <968750>;
> > > 
> > > Likewise, I see in this brief description of the regulator
> > > that the upper bound is higher than this (1.275 V). I am not sure if
> > > the values in the devicetree are supposed to describe the
> > > min/max of the regulator itself, or of what your board can really
> > > handle/needs (the latter I guess makes more sense since you wouldn't want to
> > > accidentally request a current draw that could melt something.. that can
> > > be fun). I do see you've got that min/max in the driver itself (now that
> > > I peaked at that patch).
> > Yes, your suspicions are correct and the DT sets the actual ranges
> > for the voltage regulators on this specific board while the
> > hardware reachable ranges are defined in the .c driver.
> > 
> > Konrad
> 
> Thanks Konrad, then I think:
> 
> Reviewed-by: Andrew Halaney <ahalaney@...hat.com>
> Tested-by: Andrew Halaney <ahalaney@...hat.com>
> 
> is appropriate since things are within range on all accounts. I would
> appreciate an explanation on the current min/max values though if possible!
> 

I will add a line about the range as I resubmit the patch.

Thanks,
Bjorn