Re: [PATCH v2 1/3] dt-bindings: leds: nxp,pca963x: add multicolor LED support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The schema fails to apply hardware channel limits (`reg` maximums) to the newly added `multi-led` nodes and their nested `led` subnodes.
- [Medium] The nested `led` subnodes inside `multi-led` do not require the `color` property in the schema, which is strictly required by the driver.
--

commit 8324e8da2f8fc6d6c98d977c8dcc9ab3eb3a5fcd
Author: Loic Poulain <loic.poulain@oss.qualcomm.com>

dt-bindings: leds: nxp,pca963x: add multicolor LED support

Add support for grouping individual PCA963x channels into a multicolor
LED by introducing a multi-led@N node pattern. This is necessary to
model hardware setups where multiple PWM channels drive a single physical
RGB LED.

> diff --git a/Documentation/devicetree/bindings/leds/nxp,pca963x.yaml b/Documentation/devicetree/bindings/leds/nxp,pca963x.yaml
> index 938d0e48fe51b..04b05b8195c18 100644
> --- a/Documentation/devicetree/bindings/leds/nxp,pca963x.yaml
> +++ b/Documentation/devicetree/bindings/leds/nxp,pca963x.yaml

[ ... ]

> @@ -74,6 +74,39 @@ patternProperties:
>      required:
>        - reg
>  
> +  "^multi-led@[0-9a-f]+$":
> +    type: object
> +    $ref: leds-class-multicolor.yaml#
> +    unevaluatedProperties: false
> +
> +    properties:
> +      reg:
> +        minimum: 0

[Severity: Medium]
Does this miss the hardware maximum bounds for the reg property? 

The existing allOf conditional blocks in this schema apply a maximum limit to
the reg property of top-level led nodes based on the compatible string. However,
those conditionals do not appear to target the new multi-led nodes or their
nested led subnodes, which would allow device trees with out-of-bounds channels
to silently pass validation.

> +
> +      "#address-cells":
> +        const: 1
> +
> +      "#size-cells":
> +        const: 0
> +
> +    patternProperties:
> +      "^led@[0-9a-f]+$":
> +        type: object
> +        $ref: common.yaml#
> +        unevaluatedProperties: false
> +
> +        properties:
> +          reg:
> +            minimum: 0
> +
> +        required:
> +          - reg

[Severity: Medium]
Should color be included in this required list? 

If the driver unconditionally returns an error when the color property is
missing for nested sub-LEDs, omitting it from the required list here allows
incomplete device trees to pass schema validation but fail later at runtime.

> +
> +    required:
> +      - reg
> +      - "#address-cells"
> +      - "#size-cells"
> +

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701-monza-leds-v2-0-c1be0b472926@oss.qualcomm.com?part=1