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: <20250226144548.GA2299551-robh@kernel.org>
Date: Wed, 26 Feb 2025 08:45:48 -0600
From: Rob Herring <robh@...nel.org>
To: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
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 v2 4/6] dt-bindings: thermal: rockchip: document otp
 thermal trim

On Tue, Feb 25, 2025 at 01:56:47PM +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.
> 
> 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.
> 
> Each SoC that implements this appears to have a slightly different
> combination of chip-wide trim, base, base fractional part and
> per-channel trim, so which ones do which is documented in the bindings.
> 
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
> ---
>  .../bindings/thermal/rockchip-thermal.yaml         | 64 ++++++++++++++++++++++
>  1 file changed, 64 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml
> index 49ceed68c92ce5a32ed8d4f39bd88fd052de0e80..eef8d2620b675fe2f871a03aebdaed13278e0884 100644
> --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml
> +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml
> @@ -11,6 +11,23 @@ maintainers:
>  
>  $ref: thermal-sensor.yaml#
>  
> +definitions:

'$defs' is preferred over 'definitions'. However, I don't think you need 
either.

> +  channel:

Just make this a pattern property:

'@[0-5]$'

Really, node names should be generic and the type of thing they are, not 
what instance they are. So something like 'sensor' for all the child 
nodes. IOW, node names is not how you should identify what each sensor 
is associated with.

> +    type: object
> +    properties:
> +      reg:
> +        maxItems: 1
> +        description: sensor ID, a.k.a. channel number
> +      nvmem-cells:
> +        items:
> +          - description: handle of cell containing the calibration data
> +      nvmem-cell-names:
> +        items:
> +          - const: trim
> +    required:
> +      - reg
> +    unevaluatedProperties: false
> +
>  properties:
>    compatible:
>      enum:
> @@ -51,6 +68,12 @@ properties:
>        - const: tsadc
>        - const: tsadc-phy
>  
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 0
> +
>    "#thermal-sensor-cells":
>      const: 1
>  
> @@ -80,6 +103,47 @@ required:
>    - clock-names
>    - resets
>  
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: rockchip,rk3568-tsadc
> +    then:
> +      properties:
> +        nvmem-cells:
> +          items:
> +            - 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:
> +          items:
> +            - const: trim_base
> +            - const: trim_base_frac

Define all properties at the top-level and then restrict their presence 
in the if/then schema.

> +        cpu@0:
> +          $ref: "#/definitions/channel"
> +        gpu@1:
> +          $ref: "#/definitions/channel"
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: rockchip,rk3576-tsadc
> +    then:
> +      properties:
> +        soc@0:
> +          $ref: "#/definitions/channel"
> +        bigcores@1:
> +          $ref: "#/definitions/channel"
> +        littlecores@2:
> +          $ref: "#/definitions/channel"
> +        ddr@3:
> +          $ref: "#/definitions/channel"
> +        npu@4:
> +          $ref: "#/definitions/channel"
> +        gpu@5:
> +          $ref: "#/definitions/channel"
> +
>  unevaluatedProperties: false
>  
>  examples:
> 
> -- 
> 2.48.1
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ