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

[Lee Jones <lee@kernel.org>]

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).

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

-- 
Lee Jones