Re: [PATCH v7 2/4] dt-bindings: leds: nxp,pca963x: add multicolor LED support

[email protected] Fri, 24 Jul 2026 07:56:25 +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 2 potential issue(s) to consider:
- [High] The `multi-led` node incorrectly requires a unit address and a `reg` property, falsely claiming a physical PWM channel for a logical grouping and causing legacy drivers to misbehave.
- [Low] The commit message description is not capitalized, violating the LED subsystem naming conventions.
--

--- Patch [2]: [PATCH v7 2/4] dt-bindings: leds: nxp,pca963x: add multicolor LED support ---
commit 2f0b1f07fd505c331c2a3ed9b93793cfdf27bd7f
Author: Loic Poulain <[email protected]>

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

This commit adds support for grouping individual PCA963x channels into a
multicolor LED. It introduces a multi-led node pattern to model hardware
where multiple PWM channels drive a single physical RGB LED.

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

[Severity: Low]
This isn't a bug, but the description after the subsystem prefix should
be capitalized according to LED subsystem naming conventions. Should "add"
be changed to "Add"?

> diff --git a/Documentation/devicetree/bindings/leds/nxp,pca963x.yaml b/Documentation/devicetree/bindings/leds/nxp,pca963x.yaml
> --- a/Documentation/devicetree/bindings/leds/nxp,pca963x.yaml
> +++ b/Documentation/devicetree/bindings/leds/nxp,pca963x.yaml
> @@ -74,6 +74,40 @@ patternProperties:
[ ... ]
> +  "^multi-led@[0-9a-f]$":
> +    type: object
> +    $ref: leds-class-multicolor.yaml#
> +    unevaluatedProperties: false
> +
> +    properties:
> +      reg:
> +        maximum: 15
[ ... ]
> +    required:
> +      - reg
> +      - "#address-cells"
> +      - "#size-cells"

[Severity: High]
Does requiring a reg property here incorrectly assign a physical PWM channel
address to a logical grouping?

Since the multi-led node acts as a logical container for the physical LEDs,
having it claim a physical address can lead to overlapping duplicate address
conceptualization, such as both the parent multi-led node and its first child
claiming reg = <0>.

Will the existing leds-pca963x driver, which lacks multicolor support, silently
misinterpret this multi-led node as a standard single-channel monochrome LED
mapped to channel 0 and ignore the subnodes instead of safely erroring out?

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