From: Darren Hart <dvhart@infradead.org>
To: "Michał Kępień" <kernel@kempniu.pl>
Cc: Jonathan Woithe <jwoithe@just42.net>,
Andy Shevchenko <andy@infradead.org>,
platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/6] platform/x86: fujitsu-laptop: do not log LED registration failures
Date: Mon, 17 Apr 2017 09:09:52 -0700 [thread overview]
Message-ID: <20170417160952.GA27550@fury> (raw)
In-Reply-To: <20170407130713.8417-6-kernel@kempniu.pl>
On Fri, Apr 07, 2017 at 03:07:12PM +0200, Michał Kępień wrote:
> If acpi_fujitsu_laptop_leds_register() returns an error, the latter will
> become the return value of acpi_fujitsu_laptop_add(), which in turn will
> be reported by driver core. Simplify code by replacing pr_err() calls
> with return statements. Return 0 instead of result when no errors occur
> in order to make the code easier to read.
Hi Michał,
Jonathan's comment regarding the information loss of removing the pr_err
statements seems valid to me. Based on the outer if block, I take it each
registration only fails in true error scenarios and not because some laptop
might have one but not another LED in the list. If so, then the pr_err messages
would only appear when there was a legitimate problem. I think they're worth
This seems to introduce a behavior change as well. Previously only the last
LED registered would determine the result - which is wrong of course and I
believe you noted a related bug in an early patch. Previously, however, if
LOGOLAMP_POWERON failed, for example, the KEYBOARD_LAMPS would still be attempted.
So the question really comes down to this: Is there a legitimate situation in
which one LEDs registration fails and another succeeds? If so, then this would
constitute a regression for such systems.
>
> Signed-off-by: Michał Kępień <kernel@kempniu.pl>
> ---
> drivers/platform/x86/fujitsu-laptop.c | 16 ++++++----------
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
> index ce658789e748..177b9b57ac2f 100644
> --- a/drivers/platform/x86/fujitsu-laptop.c
> +++ b/drivers/platform/x86/fujitsu-laptop.c
> @@ -739,22 +739,20 @@ static struct led_classdev eco_led = {
>
> static int acpi_fujitsu_laptop_leds_register(struct acpi_device *device)
> {
> - int result = 0;
> + int result;
>
> if (call_fext_func(FUNC_LEDS, 0x0, 0x0, 0x0) & LOGOLAMP_POWERON) {
> result = devm_led_classdev_register(&device->dev,
> &logolamp_led);
> if (result)
> - pr_err("Could not register LED handler for logo lamp, error %i\n",
> - result);
> + return result;
> }
>
> if ((call_fext_func(FUNC_LEDS, 0x0, 0x0, 0x0) & KEYBOARD_LAMPS) &&
> (call_fext_func(FUNC_BUTTONS, 0x0, 0x0, 0x0) == 0x0)) {
> result = devm_led_classdev_register(&device->dev, &kblamps_led);
> if (result)
> - pr_err("Could not register LED handler for keyboard lamps, error %i\n",
> - result);
> + return result;
> }
>
> /*
> @@ -766,8 +764,7 @@ static int acpi_fujitsu_laptop_leds_register(struct acpi_device *device)
> if (call_fext_func(FUNC_BUTTONS, 0x0, 0x0, 0x0) & BIT(24)) {
> result = devm_led_classdev_register(&device->dev, &radio_led);
> if (result)
> - pr_err("Could not register LED handler for radio LED, error %i\n",
> - result);
> + return result;
> }
>
> /* Support for eco led is not always signaled in bit corresponding
> @@ -779,11 +776,10 @@ static int acpi_fujitsu_laptop_leds_register(struct acpi_device *device)
> (call_fext_func(FUNC_LEDS, 0x2, ECO_LED, 0x0) != UNSUPPORTED_CMD)) {
> result = devm_led_classdev_register(&device->dev, &eco_led);
> if (result)
> - pr_err("Could not register LED handler for eco LED, error %i\n",
> - result);
> + return result;
> }
>
> - return result;
> + return 0;
> }
>
> static int acpi_fujitsu_laptop_add(struct acpi_device *device)
> --
> 2.12.2
>
>
--
Darren Hart
VMware Open Source Technology Center
next prev parent reply other threads:[~2017-04-17 16:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 13:07 [PATCH 0/6] fujitsu-laptop: LED cleanup Michał Kępień
2017-04-07 13:07 ` [PATCH 1/6] platform/x86: fujitsu-laptop: select LEDS_CLASS Michał Kępień
2017-04-07 13:07 ` [PATCH 2/6] platform/x86: fujitsu-laptop: refactor LED registration Michał Kępień
2017-04-07 13:07 ` [PATCH 3/6] platform/x86: fujitsu-laptop: reorganize LED-related code Michał Kępień
2017-04-07 13:07 ` [PATCH 4/6] platform/x86: fujitsu-laptop: switch to managed LED class devices Michał Kępień
2017-04-07 13:07 ` [PATCH 5/6] platform/x86: fujitsu-laptop: do not log LED registration failures Michał Kępień
2017-04-17 16:09 ` Darren Hart [this message]
2017-04-18 8:10 ` Michał Kępień
2017-04-18 16:01 ` Darren Hart
2017-04-19 7:30 ` Jonathan Woithe
2017-04-07 13:07 ` [PATCH 6/6] platform/x86: fujitsu-laptop: simplify error handling in acpi_fujitsu_laptop_add() Michał Kępień
2017-04-13 6:49 ` [PATCH 0/6] fujitsu-laptop: LED cleanup Jonathan Woithe
2017-04-13 7:13 ` Michał Kępień
2017-04-17 9:48 ` Jonathan Woithe
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=20170417160952.GA27550@fury \
--to=dvhart@infradead.org \
--cc=andy@infradead.org \
--cc=jwoithe@just42.net \
--cc=kernel@kempniu.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.