linux-kernel - Re: [PATCH 4/6] dt-bindings: thermal: rockchip: document otp thermal trim

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: <4631308.LvFx2qVVIh@workhorse>
Date: Fri, 21 Feb 2025 14:27:58 +0100
From: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
To: Rob Herring <robh@...nel.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
 Daniel Lezcano <daniel.lezcano@...aro.org>, Zhang Rui <rui.zhang@...el.com>,
 Lukasz Luba <lukasz.luba@....com>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
 Sebastian Reichel <sebastian.reichel@...labora.com>, kernel@...labora.com,
 linux-pm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Subject:
 Re: [PATCH 4/6] dt-bindings: thermal: rockchip: document otp thermal trim

On Thursday, 20 February 2025 00:10:36 Central European Standard Time Rob 
Herring wrote:
> On Sun, Feb 16, 2025 at 12:34:53AM +0100, Nicolas Frattaroli wrote:
> > Several Rockchip SoCs, such as the RK3576, can store calibration trim
> > data for thermal sensors in OTP cells. This capability should be
> > documented.
> 
> Is several most or a minority as this change is enabled for everyone.

Downstream has trim_h/trim_l nodes for the following SoCs:
- RK3502
- RK3528
- RK3562
- RK3566
- RK3568
- RK3576
- RV1126

If you'd prefer I split the bindings or add a conditional to only enable this 
on those specific compatibles, let me know. It is worth noting that all of 
these SoCs are fairly new, so I assume this is the design that Rockchip is 
using going forward.

Additionally, trim_base/trim_base_frac seem to only be set in downstream DTs 
for RK3562, RK3566, RK3568 and RV1126, so while I'm at it I'd add those to a 
separate conditional as well.

> > Such a rockchip thermal sensor may reference cell handles that store
> > both a chip-wide trim for all the sensors, as well as cell handles
> > for each individual sensor channel pointing to that specific sensor's
> > trim value.
> > 
> > Additionally, the thermal sensor may optionally reference cells which
> > store the base in terms of degrees celsius and decicelsius that the trim
> > is relative to.
> > 
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
> > ---
> > 
> >  .../bindings/thermal/rockchip-thermal.yaml         | 44
> >  ++++++++++++++++++++++ 1 file changed, 44 insertions(+)
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml
> > b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml index
> > 49ceed68c92ce5a32ed8d4f39bd88fd052de0e80..8d27ddefcc64e29f0faab0598888058
> > 02c948b41 100644 ---
> > a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml +++
> > b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml> 
> > @@ -40,6 +40,21 @@ properties:
> >        - const: tsadc
> >        - const: apb_pclk
> > 
> > +  nvmem-cells:
> > +    items:
> > +      - description: cell handle of the low byte of the chip fallback
> > trim value +      - description: cell handle of the high byte of the chip
> > fallback trim value +      - description: cell handle to where the trim's
> > base temperature is stored +      - description:
> > +          cell handle to where the trim's tenths of Celsius base value is
> > stored +
> > +  nvmem-cell-names:
> > +    enum:
> > +      - trim_l
> > +      - trim_h
> > +      - trim_base
> > +      - trim_base_frac
> > +
> > 
> >    resets:
> >      minItems: 1
> >      maxItems: 3
> > 
> > @@ -51,6 +66,12 @@ properties:
> >        - const: tsadc
> >        - const: tsadc-phy
> > 
> > +  "#address-cells":
> > +    const: 1
> > +
> > +  "#size-cells":
> > +    const: 0
> > +
> > 
> >    "#thermal-sensor-cells":
> >      const: 1
> > 
> > @@ -72,6 +93,29 @@ properties:
> >      $ref: /schemas/types.yaml#/definitions/uint32
> >      enum: [0, 1]
> > 
> > +patternProperties:
> 
> > +  "^([a-z]+)@[0-9]+$":
> If each node is a sensor or channel, then make that the node name.

Will do in V2. Should the node name be something like e.g. `gpu` for the GPU 
thermal sensor/channel? Maybe suffixed with e.g. `-tsadc` or something, to 
disambiguate it from other mentions of the GPU, or is disambiguation 
unnecessary noise because it's evident from it being a child of tsadc anyway, 
much like cpu and codec aren't suffixed with anything in simple-audio-card's 
dai-link?

> 
> > +    type: object
> > +    properties:
> > +      reg:
> > +        maxItems: 1
> > +        description: sensor ID, a.k.a. channel number
> > +
> > +      nvmem-cells:
> > +        items:
> > +          - description: handle of cell containing low byte of
> > calibration data +          - description: handle of cell containing high
> > byte of calibration data +
> > +      nvmem-cell-names:
> > +        items:
> > +          - const: trim_l
> > +          - const: trim_h
> > +
> > +    required:
> > +      - reg
> > +
> > +    unevaluatedProperties: false
> > +
> > 
> >  required:
> >    - compatible
> >    - reg