Re: [PATCH v6 1/4] dt-bindings: leds: nxp,pca963x: fix reg maximum for pca9635

[email protected] Wed, 15 Jul 2026 13:51:55 +0000
Newsgroups org.kernel.vger.linux-leds,org.kernel.vger.linux-devicetree
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message claims to tighten the node name regex from `[0-9a-f]+` to `[0-9a-f]` to match the single-digit hardware limit. However, this change was only applied to the top-level `patternProperties`. The corresponding regexes inside the `allOf` conditional blocks for older chip generations were neglected and still allow multiple hex digits.
--

--- Patch [1]: [PATCH v6 1/4] dt-bindings: leds: nxp,pca963x: fix reg maximum for pca9635 ---
commit a500d493e0680c38dffc3b668e4fe9888ec4d0bd
Author: Loic Poulain <[email protected]>
Subject: dt-bindings: leds: nxp,pca963x: fix reg maximum for pca9635

This commit increases the maximum reg value to 15 in the top-level led node
to support 16 channels on the pca9635. It refactors the allOf conditionals
to give pca9634 its own block and changes the top-level regex constraint to
match a single hexadecimal digit.

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

[ ... ]

> @@ -88,7 +88,13 @@ allOf:
>            properties:
>              reg:
>                maximum: 3
> -    else:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - nxp,pca9634
> +    then:
>        patternProperties:
>          "^led@[0-9a-f]+$":

[Severity: Medium]
The commit message states the regex is tightened to single-digit [0-9a-f],
but is it intentional that the patternProperties inside the allOf blocks for
older generations still use the multiple-digit [0-9a-f]+ pattern?

While the top-level constraint handles the validation correctly, retaining
the '+' in the nested conditional blocks for pca9634 (and the pca9632 and
pca9633 block just above this hunk) leaves the schema internally
inconsistent with the stated intent.

>            properties:
>              reg:

-- 
Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1