Re: [PATCH v2 1/6] dt-bindings: thermal: thermal-zones: add hardware-binning trip properties

From: Krzysztof Kozlowski

Date: Wed Nov 04 2026 - 07:44:22 EST


On Sat, Oct 31, 2026 at 06:52:47PM +0530, Gaurav Kohli wrote:
> From: Amit Kucheria <amit.kucheria@xxxxxxxxxxxxxxxx>
>
> Differences in SoC packaging can be used to provide multiple SoC SKUs at
> different thermal and performance characteristics. The underlying SoC
> remains the same except for how much heat the packaging can dissipate,
> thereby influencing the critical trip point at which an SoC SKU needs to
> be throttled. This SKU-specific data is typically burned into fuses
> during manufacturing and can be read back at runtime.
>
> Add two optional trip-point properties to describe this:
>
> - 'temperature-bin': an array of per-bin trip temperatures, used
> instead of 'temperature' when the trip depends on the hardware
> revision encoded in fuses.
>
> - 'thermal-hw-bin': one or more bitmask groups describing the hardware
> revisions for which a trip point is valid, modeled on the
> 'opp-supported-hw' property of the OPP framework.
>
> Signed-off-by: Amit Kucheria <amit.kucheria@xxxxxxxxxxxxxxxx>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@xxxxxxxxxxxxxxxx>
> ---
> .../devicetree/bindings/thermal/thermal-zones.yaml | 57 +++++++++++++++++++++-
> 1 file changed, 56 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
> index 999ad40a20d5..62590dfc77bf 100644
> --- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
> +++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
> @@ -152,6 +152,55 @@ patternProperties:
> situation where the trip gets constantly triggered soon after
> cooling action is removed.
>
> + temperature-bin:
> + $ref: /schemas/types.yaml#/definitions/int32-array
> + items:
> + minimum: -273000
> + maximum: 200000
> + description: |
> + An array of integers expressing trip temperatures in
> + millicelsius, one entry per hardware bin sub-group defined
> + in the thermal-hw-bin property. Each value is the trip
> + temperature for the corresponding hardware bin.
> +
> + Use this property instead of 'temperature' when the trip
> + temperature depends on the SoC hardware revision as encoded
> + in fuse values. The platform driver reads the fuse and
> + registers the hardware-version bitfields with the thermal
> + zone; the framework then selects the matching entry.
> +
> + Exactly one of 'temperature' or 'temperature-bin' must be
> + present in each trip node.
> +
> + thermal-hw-bin:
> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> + description: |
> + Optional bitmask(s) describing the hardware revisions for
> + which this trip point is valid.
> +
> + Uses the same format and semantics as the opp-supported-hw
> + property in the OPP framework. The platform provides N
> + 32-bit values describing the hardware it is running on.

', in a format specific to the thermal sensor provided in
"thermal-sensors" property.'

This basically ties it to the thermal sensor which will disallow growing
the thermal-sensors to more than one phandle. The plural in
"thermal-sensors" name is confusing...

> + Each trip node may provide one or more groups of N 32-bit
> + mask values.
> +
> + The total number of 32-bit cells must be a multiple of N.
> + Each contiguous group of N cells forms a sub-group. A
> + sub-group matches if, for all i in [0 .. N-1], the bitwise
> + AND of the i-th mask and the i-th platform hardware value
> + is non-zero. The trip point is enabled if any sub-group
> + matches. If multiple sub-groups match, the first matching
> + sub-group selects the corresponding temperature-bin entry.
> +
> + When used together with 'temperature-bin', the number of
> + sub-groups must equal the number of entries in
> + 'temperature-bin'.
> +
> + If absent, the trip point is valid for all hardware.

minItems: 1
maxItems: 32

Best regards,
Krzysztof