Re: [PATCH v2 12/12] dt-bindings: thermal: cooling-devices: Update support for 3 cells cooling device

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [High] Schema Validation Loophole: Relaxing the global `#cooling-cells` property allows invalid device tree configurations to pass schema validation.
--

commit 4d1db5332aa8215862512cf05a640de7afe86998
Author: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>

dt-bindings: thermal: cooling-devices: Update support for 3 cells cooling device

This commit extends the thermal cooling device binding to support a 3 cells
specifier in addition to the 2 cells format. It updates the core
#cooling-cells property to an enum allowing both 2 and 3 arguments, and
adds an explicit constraint to pwm-fan.yaml.

> diff --git a/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml b/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
> --- a/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
> +++ b/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
[ ... ]
> @@ -44,10 +44,14 @@ select: true
>  properties:
>    "#cooling-cells":
>      description:
> -      Must be 2, in order to specify minimum and maximum cooling state used in
> +      Must be 2 or 3. If 2, specifies minimum and maximum cooling state used in
>        the cooling-maps reference. The first cell is the minimum cooling state
>        and the second cell is the maximum cooling state requested.
> -    const: 2
> +      If 3, the first cell specifies the thermal mitigation device specifier
> +      index for devices that support multiple thermal mitigation mechanisms.
> +      The two other cells are respectively the minimum cooling state and the
> +      maximum cooling state.
> +    enum: [2, 3]

By relaxing the core schema to allow 3 cells globally, does this
unintentionally create a validation loophole for other cooling providers?

Many specific cooling provider bindings (such as nvidia,tegra210-emc.yaml
or CPU nodes via arm/cpus.yaml) completely omitted local #cooling-cells
constraints because they relied entirely on this core schema to enforce
const: 2.

Since the core schema now allows 3 cells, any device binding lacking an
explicit const: 2 override will silently accept 3 cells, even if the
hardware or driver only supports 2. 

Have all other existing cooling providers been audited and updated to ensure
they have a local const: 2 constraint where needed, similar to what was done
for pwm-fan.yaml?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260422174305.2899095-1-daniel.lezcano@oss.qualcomm.com?part=12