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]
Date:   Thu, 12 Jul 2018 11:26:25 +0530
From:   Amit Kucheria <amit.kucheria@...aro.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Eduardo Valentin <edubezval@...il.com>,
        smohanad@...eaurora.org,
        Vivek Gautam <vivek.gautam@...eaurora.org>,
        Andy Gross <andy.gross@...aro.org>,
        Zhang Rui <rui.zhang@...el.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Linux PM list <linux-pm@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>
Subject: Re: [PATCH v6 6/7] dt: thermal: tsens: Document the fallback DT
 property for v2 of TSENS IP

On Thu, Jul 12, 2018 at 12:12 AM Doug Anderson <dianders@...omium.org> wrote:
>
> Hi,
>
> On Mon, Jul 9, 2018 at 4:43 AM, Amit Kucheria <amit.kucheria@...aro.org> wrote:
> > We want to create common code for v2 of the TSENS IP block that is used in
> > a large number of Qualcomm SoCs. "qcom,tsens-v2" should be able to handle
> > most of the common functionality start with a common get_temp() function.
> >
> > It is also necessary to split out the memory regions for the TM and SROT
> > register banks because their offsets are not constant across SoC families.
>
> nit that bindings should be earlier in the patch series than the code
> implementing the bindings.

Will reorder.

>
> > Signed-off-by: Amit Kucheria <amit.kucheria@...aro.org>
> > ---
> >  .../devicetree/bindings/thermal/qcom-tsens.txt     | 25 +++++++++++++++++-----
> >  1 file changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> > index 06195e8..8f963b1 100644
> > --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> > +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> > @@ -1,10 +1,16 @@
> >  * QCOM SoC Temperature Sensor (TSENS)
> >
> >  Required properties:
> > -- compatible :
> > - - "qcom,msm8916-tsens" : For 8916 Family of SoCs
> > - - "qcom,msm8974-tsens" : For 8974 Family of SoCs
> > - - "qcom,msm8996-tsens" : For 8996 Family of SoCs
> > +- compatible:
> > +  Must be one of the following:
> > +    - "qcom,msm8916-tsens" (MSM8916)
> > +    - "qcom,msm8974-tsens" (MSM8974)
> > +    - "qcom,msm8996-tsens" (MSM8996)
> > +    - "qcom,msm8998-tsens", "qcom,tsens-v2" (MSM8998)
> > +    - "qcom,sdm845-tsens", "qcom,tsens-v2" (SDM845)
> > +  The generic "qcom,tsens-v2" property must be used as a fallback for any SoC with
> > +  version 2 of the TSENS IP. MSM8996 is the only exception beacause the generic
> > +  property did not exist when support was added.
> >
> >  - reg: Address range of the thermal registers
>
> You need to document that for old SoCs where TM / SROT were 0x1000
> apart (SROT first) that one "reg" field was OK.  ...and that for new
> SoCs you specify two reg ranges: the first for TM and the second for
> SROT.

OK.

> >  - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
> > @@ -12,7 +18,7 @@ Required properties:
> >  - Refer to Documentation/devicetree/bindings/nvmem/nvmem.txt to know how to specify
> >  nvmem cells
> >
> > -Example:
> > +Example 1 (legacy support before a fallback tsens-v2 propoerty was introduced):
> >  tsens: thermal-sensor@...000 {
> >                 compatible = "qcom,msm8916-tsens";
> >                 reg = <0x4a8000 0x2000>;
> > @@ -20,3 +26,12 @@ tsens: thermal-sensor@...000 {
> >                 nvmem-cell-names = "caldata", "calsel";
> >                 #thermal-sensor-cells = <1>;
> >         };
> > +
> > +Example 2 (for any platform containing v2 of the TSENS IP):
> > +tsens0: tsens@...2000 {
>
> A) Use a generic name for the node, not a specific one.  Thus the node
> should be "thermal-sensor", not "tsens".
>
> B) This unit address needs to match the _first_ reg address listed.
> Give your reg below, this should be @c263000
>
> Thus your node name should be:
>
> tsens0: thermal-sensor@...3000 {

Fixed

> > +               compatible = "qcom,sdm845-tsens", "qcom,tsens-v2";
> > +               reg = <0xc263000 0x1ff>, /* TM */
> > +                       <0xc222000 0x1ff>; /* SROT */
> > +               #qcom,sensors = <13>;
>
> The "#qcom,sensors" property seems wrong in a few ways:
>
> A) I wouldn't have expected it to start with a "#".  I only expect to
> see that on things specifying sizes / lengths.  Rob can feel free to
> override me, though.
>
> B) It's not documented above.  Just putting something in an example
> doesn't document it--it needs to be listed in the "Optional
> properties".

Powered by blists - more mailing lists