From: sashiko-bot@kernel.org
To: kr494167@gmail.com
Cc: linux-leds@vger.kernel.org, lee@kernel.org
Subject: Re: [PATCH] leds: lp5860: reject out-of-range channel IDs
Date: Mon, 20 Jul 2026 10:41:49 +0000 [thread overview]
Message-ID: <20260720104149.C2C7D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720103017.88090-1-kr494167@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The commit message incorrectly claims that the malformed sub-LED uses the invalid ID for register addressing.
- [Low] The commit message description is not capitalized, violating the LED subsystem conventions.
- [Low] The patch uses `dev_err()` instead of `dev_err_probe()` to report a configuration failure.
--
--- Patch [1]: [PATCH] leds: lp5860: reject out-of-range channel IDs ---
commit 4536ff26f6ab558401ac176c54f90cdb3be700b7
Author: surendra <kr494167@gmail.com>
leds: lp5860: reject out-of-range channel IDs
This commit fixes an issue where lp5860_iterate_subleds() returns success
when encountering a channel ID that is out of bounds, instead of correctly
returning an error.
> leds: lp5860: reject out-of-range channel IDs
[Severity: Low]
This isn't a bug, but the LED subsystem guidelines require capitalizing the
description after the subsystem prefix. Should this be "Reject out-of-range
channel IDs"?
> The caller therefore treats the malformed
> sub-LED description as valid and uses the invalid ID for register
> addressing.
[Severity: Medium]
Is this description accurate?
Looking at the original code, if channel > LP5860_MAX_LED, it returns `ret`
(which is 0) and aborts the loop before assigning the parsed channel to
led->mc_cdev.subled_info[subled].channel.
Since the subled_info array is zero-filled by allocation, the unassigned
channel would remain 0 rather than containing the invalid out-of-bounds ID.
Could the commit message be updated to better reflect the exact behavior?
> diff --git a/drivers/leds/rgb/leds-lp5860-core.c b/drivers/leds/rgb/leds-lp5860-core.c
> index e21d5f2302be0..75498311b0803 100644
> --- a/drivers/leds/rgb/leds-lp5860-core.c
> +++ b/drivers/leds/rgb/leds-lp5860-core.c
> @@ -114,12 +114,18 @@ static int lp5860_iterate_subleds(struct lp5860_led *led, struct led_init_data *
> }
>
> ret = fwnode_property_read_u32(led_node, "reg", &channel);
> - if (ret < 0 || channel > LP5860_MAX_LED) {
> + if (ret < 0) {
> dev_err_probe(led->chip->dev, ret,
> "%pfwP: 'reg' property is missing. Skipping.\n", led_node);
> fwnode_handle_put(led_node);
> return ret;
> }
> + if (channel > LP5860_MAX_LED) {
> + dev_err(led->chip->dev, "%pfwP: 'reg' property is out of range.\n",
> + led_node);
[Severity: Low]
Should this use dev_err_probe() instead of dev_err() to maintain consistency
with the surrounding error paths and conform to the LED subsystem guidelines
for probe failures?
> + fwnode_handle_put(led_node);
> + return -EINVAL;
> + }
>
> led->mc_cdev.subled_info[subled].color_index = color_index;
> led->mc_cdev.subled_info[subled].channel = channel;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720103017.88090-1-kr494167@gmail.com?part=1
prev parent reply other threads:[~2026-07-20 10:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 10:30 [PATCH] leds: lp5860: reject out-of-range channel IDs kr494167
2026-07-20 10:41 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260720104149.C2C7D1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kr494167@gmail.com \
--cc=lee@kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox