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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Schema validation bypass for nested physical LED channels inside multi-led nodes.
--

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

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

This commit adds support for grouping individual PCA963x channels into a
multicolor LED by introducing a multi-led@N node pattern. It follows the
convention established by other multicolor LED drivers.

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

[ ... ]

> @@ -84,13 +117,13 @@ allOf:
>                - nxp,pca9633
>      then:
>        patternProperties:
> -        "^led@[0-9a-f]+$":
> +        "^.*led@[0-9a-f]+$":

[Severity: Low]
Does this pattern property correctly enforce the maximum limit on nested LED
channels?

Since JSON schema patternProperties evaluate at the current object level and
do not recurse, wouldn't changing this regex only apply the maximum reg
constraint to the multi-led node itself, completely bypassing the limit
for the nested physical hardware channels?

>            properties:
>              reg:
>                maximum: 3
>      else:
>        patternProperties:
> -        "^led@[0-9a-f]+$":
> +        "^.*led@[0-9a-f]+$":
>            properties:
>              reg:
>                maximum: 7

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