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