From: sashiko-bot@kernel.org
To: "Steve Dunnagan" <sdunnaga@redhat.com>
Cc: linux-leds@vger.kernel.org, lee@kernel.org
Subject: Re: [PATCH v2] leds: gpio: Clear error pointers for skipped LEDs
Date: Fri, 24 Jul 2026 18:16:07 +0000 [thread overview]
Message-ID: <20260724181607.7B84C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260724180412.43150-1-sdunnaga@redhat.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The driver masks -EPROBE_DEFER from GPIO fetching functions and incorrectly skips the LED instead of deferring the probe.
--
--- Patch [1]: [PATCH v2] leds: gpio: Clear error pointers for skipped LEDs ---
commit 2d09674f074f178fbc54110548c9a0816564760c
Author: Steve Dunnagan <sdunnaga@redhat.com>
leds: gpio: Clear error pointers for skipped LEDs
When an LED's GPIO is unavailable, the error pointer is left in led_dat->gpiod.
During shutdown this error pointer is passed to gpio_led_set(), producing an
invalid GPIO warning. This commit clears the error pointer to prevent the
warning.
> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> index 8ae71c2e91e01..8810fdcf2d774 100644
> --- a/drivers/leds/leds-gpio.c
> +++ b/drivers/leds/leds-gpio.c
> @@ -277,6 +277,7 @@ static int gpio_led_probe(struct platform_device *pdev)
> if (IS_ERR(led_dat->gpiod)) {
> dev_info(dev, "Skipping unavailable LED gpio %d (%s)\n",
> template->gpio, template->name);
[Severity: High]
This isn't a bug introduced by this patch, but does this unconditionally skip
the LED even if gpio_led_get_gpiod() returns -EPROBE_DEFER?
If the GPIO controller providing the LED pins hasn't probed yet,
gpio_led_get_gpiod() returns ERR_PTR(-EPROBE_DEFER) to gpio_led_probe(). By
catching all error pointers with IS_ERR() here and continuing, the driver
completes the probe without the deferred LED instead of actually deferring,
permanently breaking the LED's functionality.
Would it be better to use dev_err_probe() here to correctly handle
-EPROBE_DEFER?
> + led_dat->gpiod = NULL;
> continue;
> }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260724180412.43150-1-sdunnaga@redhat.com?part=1
next prev parent reply other threads:[~2026-07-24 18:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 15:08 [PATCH] leds: gpio: Skip unavailable LEDs during shutdown Steve Dunnagan
2026-07-10 15:21 ` sashiko-bot
2026-07-23 11:35 ` Lee Jones
2026-07-24 18:04 ` [PATCH v2] leds: gpio: Clear error pointers for skipped LEDs Steve Dunnagan
2026-07-24 18:16 ` sashiko-bot [this message]
2026-07-25 14:02 ` Linus Walleij
2026-08-06 13:52 ` (subset) " Lee Jones
2026-08-13 15:45 ` Steve Dunnagan
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=20260724181607.7B84C1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=lee@kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sdunnaga@redhat.com \
/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