Re: [PATCH 1/1] dt-bindings: hwmon: tmp102: move ti,tmp103 out of trivial-devices.yaml

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `#thermal-sensor-cells` property is defined with an `enum` instead of a `const` constraint, violating DT binding rules.
- [Medium] The `ti,tmp103` compatible string is added to a schema that globally allows the `interrupts` property, despite the TMP103 hardware lacking an interrupt pin.
--

commit 8ed50c8d65316077824330117ca798258a318903
Author: Frank Li <Frank.Li@nxp.com>

dt-bindings: hwmon: tmp102: move ti,tmp103 out of trivial-devices.yaml

Move the ti,tmp103 binding from trivial-devices.yaml to ti,tmp102.yaml.
Both devices are single temperature sensors. This commit also updates the
"#thermal-sensor-cells" property to accept values 0 and 1.

> diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml
> --- a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml
> @@ -13,6 +13,7 @@ properties:
>    compatible:
>      enum:
>        - ti,tmp102
> +      - ti,tmp103
>  
>    interrupts:
>      maxItems: 1

[Severity: Medium]
Does adding ti,tmp103 here without additional constraints allow device trees
to incorrectly define an interrupts property for the TMP103?

The TMP103 hardware lacks an interrupt pin. Because the interrupts property
is globally permitted in this schema, the schema validation might silently
pass invalid configurations that declare interrupts for ti,tmp103 nodes.

Should there be an allOf: if: conditional block to explicitly restrict the
interrupts property only to compatibles that actually support it?

[ ... ]

> @@ -25,7 +26,7 @@ properties:
>        A descriptive name for this channel, like "ambient" or "psu".
>  
>    "#thermal-sensor-cells":
> -    const: 1
> +    enum: [0, 1]

[Severity: Medium]
Does changing this constraint to an enum bypass the device tree binding
rules?

Subsystem guidelines indicate that cell-count properties need a strict const
constraint matching the hardware. If the schema allows both 0 and 1 cells
for all hardware configurations, it might fail to catch incorrect cell count
assignments in device tree nodes during build-time validation.

Would it be better to enforce const: 0 or const: 1 for specific hardware
variants using conditional blocks based on the compatible string?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826211422.3299728-1-Frank.Li@oss.nxp.com?part=1