Re: [PATCH 1/7] dt-bindings: leds: pca995x: describe reset-gpios property

[Nora Schiffer <nora.schiffer@ew.tq-group.com>]

On Wed, 2026-09-02 at 17:16 +0100, Lee Jones wrote:
> On Wed, 02 Sep 2026, sashiko-bot@kernel.org wrote:
> 
> > Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> > 
> > New issues:
> > - [Low] The commit message description is not capitalized, violating the LED subsystem guidelines.
> 
> Please review, explain or fix the Sashiko review(s).

Hi Lee,

please see my reply to the Sashiko review on PATCH 2/7, as that one requires a
decision how we want to model the output-gain in the Device Tree. All other
Sashiko review comments look correct and will be addressed in v2.

Best,
Nora


> 
> If this is a set, this request includes the other patches too.
> 
> > Pre-existing issues:
> > - [High] This problem wasn't introduced by this patch, but the driver validates the child `reg` property against `PCA995X_MAX_OUTPUTS` (24) instead of the chip-specific `num_leds`. This allows 16-channel variants to configure out-of-bounds LEDs.
> > --
> > 
> > commit ead1262f70ad0044c0eca7c693a6d898fbcc4d44
> > Author: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> > 
> > dt-bindings: leds: pca995x: describe reset-gpios property
> > 
> > This commit adds the reset-gpios property to the PCA995x device tree binding.
> > It allows the reset pin of the PCA995x to be described in the Device Tree.
> > 
> > > dt-bindings: leds: pca995x: describe reset-gpios property
> > 
> > [Severity: Low]
> > This isn't a bug, but does this commit message subject violate the LED
> > subsystem capitalization rules? The description after the subsystem prefix
> > should be capitalized.
> > 
> > This is a pre-existing issue, but the driver validates the child reg
> > property against PCA995X_MAX_OUTPUTS (24) instead of the chip-specific
> > num_leds:
> > 
> > drivers/leds/leds-pca995x.c:pca995x_probe() {
> >     ...
> > 	device_for_each_child_node_scoped(dev, child) {
> > 		ret = fwnode_property_read_u32(child, "reg", &reg);
> > 		if (ret)
> > 			return ret;
> > 
> > 		if (reg < 0 || reg >= PCA995X_MAX_OUTPUTS || led_fwnodes[reg])
> > 			return -EINVAL;
> >     ...
> > }
> > 
> > [Severity: High]
> > Does this allow 16-channel variants to configure out-of-bounds LEDs?
> > 
> > Changing the brightness of out-of-bounds LED channels (16-23) on 16-channel
> > variants (e.g. PCA9955B) calculates a pwmout_addr that overlaps with the
> > IREF registers (output current control) for channels 0-7.
> > 
> > Could this cause silent hardware state corruption and potential physical
> > damage to LEDs?
> > 
> > -- 
> > Sashiko AI review · https://sashiko.dev/#/patchset/6d3600f99c77c31166f0b6a5ccfb7f518b53c4c9.1788350618.git.nora.schiffer@ew.tq-group.com?part=1
> 

-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/