From: Lee Jones <lee@kernel.org>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>,
"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>
Subject: Re: [PATCH] leds: core: Omit set_brightness error message for a LED supporting hw trigger only
Date: Thu, 2 May 2024 17:11:30 +0100 [thread overview]
Message-ID: <20240502161130.GW5338@google.com> (raw)
In-Reply-To: <1b425a70-48e2-4733-8e05-225695109ceb@gmail.com>
On Thu, 11 Apr 2024, Heiner Kallweit wrote:
> On 11.04.2024 16:26, Lee Jones wrote:
> > On Fri, 05 Apr 2024, Heiner Kallweit wrote:
> >
> >> If both set_brightness functions return -ENOTSUPP, then the LED doesn't
> >> support setting a fixed brightness value, and the error message isn't
> >> helpful. This can be the case e.g. for LEDs supporting a specific hw
> >> trigger only.
> >>
> >> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> >> ---
> >> drivers/leds/led-core.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
> >> index 89c9806cc..9485f799f 100644
> >> --- a/drivers/leds/led-core.c
> >> +++ b/drivers/leds/led-core.c
> >> @@ -127,7 +127,8 @@ static void set_brightness_delayed_set_brightness(struct led_classdev *led_cdev,
> >> ret = __led_set_brightness(led_cdev, value);
> >> if (ret == -ENOTSUPP)
> >> ret = __led_set_brightness_blocking(led_cdev, value);
> >> - if (ret < 0 &&
> >> + /* Don't emit error message if LED supports a hw trigger like netdev only */
> >> + if (ret < 0 && ret != -ENOTSUPP &&
> >> /* LED HW might have been unplugged, therefore don't warn */
> >> !(ret == -ENODEV && (led_cdev->flags & LED_UNREGISTERING) &&
> >> (led_cdev->flags & LED_HW_PLUGGABLE)))
> >
> > This function is already pretty messy.
> >
> > How about something like:
> >
> > static void set_brightness_delayed_set_brightness(struct led_classdev *led_cdev,
> > unsigned int value)
> > {
> > int ret;
> >
> > ret = __led_set_brightness(led_cdev, value);
> > if (ret == -ENOTSUPP) {
> > ret = __led_set_brightness_blocking(led_cdev, value);
> > if (ret == -ENOTSUPP)
> > /* No back-end support to set a fixed brightness value */
> > return;
> > }
> >
> > if (ret == -ENODEV && (led_cdev->flags & LED_UNREGISTERING))
> > /* LED HW might have been unplugged, therefore don't warn */
> > return;
> >
> > if (ret < 0 && led_cdev->flags & LED_HW_PLUGGABLE)
> > dev_err(led_cdev->dev, "Setting an LED's brightness failed (%d)\n", ret);
> > }
> >
> I think this would be a functional change. If:
> ret = -ENODEV
> led_cdev->flags & LED_UNREGISTERING is true
> led_cdev->flags & LED_HW_PLUGGABLE is false
>
> Current code would warn, proposed new code not.
>
> But I like the idea. Proposal:
>
> static void set_brightness_delayed_set_brightness(struct led_classdev *led_cdev,
> unsigned int value)
> {
> int ret;
>
> ret = __led_set_brightness(led_cdev, value);
> if (ret == -ENOTSUPP) {
> ret = __led_set_brightness_blocking(led_cdev, value);
> if (ret == -ENOTSUPP)
> /* No back-end support to set a fixed brightness value */
> return;
> }
>
> /* LED HW might have been unplugged, therefore don't warn */
> if (ret == -ENODEV && led_cdev->flags & LED_UNREGISTERING &&
> led_cdev->flags & LED_HW_PLUGGABLE)
> return;
>
> if (ret < 0)
> dev_err(led_cdev->dev,
> "Setting an LED's brightness failed (%d)\n", ret);
> }
>
> Fine with me if you submit the patch.
Sorry, it's been a busy few weeks.
Just so you know, this is still on my radar.
I plan on submitting this for the next cycle.
--
Lee Jones [李琼斯]
prev parent reply other threads:[~2024-05-02 16:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-05 20:58 [PATCH] leds: core: Omit set_brightness error message for a LED supporting hw trigger only Heiner Kallweit
2024-04-11 14:26 ` Lee Jones
2024-04-11 14:27 ` Lee Jones
2024-04-11 20:46 ` Heiner Kallweit
2024-05-02 16:11 ` Lee Jones [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=20240502161130.GW5338@google.com \
--to=lee@kernel.org \
--cc=hkallweit1@gmail.com \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).