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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <65020eb3.7b0a0220.fada9.b703@mx.google.com>
Date:   Wed, 13 Sep 2023 21:34:06 +0200
From:   Christian Marangi <ansuelsmth@...il.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Robert Marko <robimarko@...il.com>, ilia.lin@...nel.org,
        vireshk@...nel.org, nm@...com, sboyd@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
        rafael@...nel.org, agross@...nel.org, andersson@...nel.org,
        konrad.dybcio@...aro.org, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, dmitry.baryshkov@...aro.org
Subject: Re: [PATCH v3 2/3] dt-bindings: opp: opp-v2-kryo-cpu: Document named
 opp-microvolt property

On Tue, Sep 12, 2023 at 10:42:39AM -0500, Rob Herring wrote:
> On Sat, Sep 09, 2023 at 06:56:01PM +0200, Robert Marko wrote:
> > From: Christian Marangi <ansuelsmth@...il.com>
> > 
> > Document named opp-microvolt property for opp-v2-kryo-cpu schema.
> > This property is used to declare multiple voltage ranges selected on the
> > different values read from efuses. The selection is done based on the
> > speed pvs values and the named opp-microvolt property is selected by the
> > qcom-cpufreq-nvmem driver.
> > 
> > Signed-off-by: Christian Marangi <ansuelsmth@...il.com>
> > Signed-off-by: Robert Marko <robimarko@...il.com>
> > ---
> >  .../bindings/opp/opp-v2-kryo-cpu.yaml         | 40 +++++++++++++++++++
> >  1 file changed, 40 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
> > index bbbad31ae4ca..6f216306a7eb 100644
> > --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
> > +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
> > @@ -63,6 +63,12 @@ patternProperties:
> >            5:  MSM8996SG, speedbin 1
> >            6:  MSM8996SG, speedbin 2
> >            7-31:  unused
> > +
> > +          Bitmap for IPQ806X SoC:
> > +          0:  IPQ8062
> > +          1:  IPQ8064/IPQ8066/IPQ8068
> > +          2:  IPQ8065/IPQ8069
> > +          3-31:  unused
> >          enum: [0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7,
> >                 0x9, 0xd, 0xe, 0xf,
> >                 0x10, 0x20, 0x30, 0x70]
> > @@ -71,6 +77,24 @@ patternProperties:
> >  
> >        required-opps: true
> >  
> > +    patternProperties:
> > +      '^opp-microvolt-speed[0-9]+-pvs[0-9]+$':
> > +        description: |
> > +          Named opp-microvolt property following the same generic
> > +          binding for named opp-microvolt.
> > +
> > +          The correct voltage range is selected based on the values
> > +          in the efuse for the speed and the pvs.
> 
> What is "pvs"?
>

I will add the meaning in ().  

> > +
> > +          The qcom-cpufreq-nvmem driver will read all these values
> > +          and assign the correct named property.
> 
> Specific driver details don't belong in binding. If there's some detail 
> or requirement of all consumers, then that is fine here.
> 

Ok will drop.

> > +        $ref: /schemas/types.yaml#/definitions/uint32-matrix
> 
> The common binding already defines the type. Drop.
> 
> > +        minItems: 1
> > +        maxItems: 8   # Should be enough regulators
> 
> Does this really vary from 1 to 8 entries? Looks like copy-n-paste.
> 

Yes this comes from the default opp schema, actually the thing can
support 4 regulators so I will change to that.

> > +        items:
> > +          minItems: 1
> > +          maxItems: 3
> 
> Do you really need to support both single voltage and <nom min max> 
> forms?
>

It's all part of the OPP declaration so it would be supported anyway. Ok
for me to enforce <nom min max>. But is it really necessary?

-- 
	Ansuel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ