X86 platform drivers
 help / color / mirror / Atom feed
From: Jonathan Woithe <jwoithe@just42.net>
To: Micha?? K??pie?? <kernel@kempniu.pl>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Darren Hart <dvhart@infradead.org>,
	Platform Driver <platform-driver-x86@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] platform/x86: fujitsu-laptop: rework logolamp_set() to properly handle errors
Date: Sat, 7 Jan 2017 11:31:24 +1030	[thread overview]
Message-ID: <20170107010124.GA4631@marvin.atrad.com.au> (raw)
In-Reply-To: <20170106192431.GB756@kmp-mobile.hq.kempniu.pl>

On Fri, Jan 06, 2017 at 08:24:31PM +0100, Micha?? K??pie?? wrote:
> > On Thu, Jan 5, 2017 at 3:11 PM, Micha?? K??pie?? <kernel@kempniu.pl> wrote:
> > > Potential errors returned by some call_fext_func() calls inside
> > > logolamp_set() are currently ignored.  Rework logolamp_set() to properly
> > > handle them.  This causes one more call_fext_func() call to be made in
> > > the LED_OFF case, though one could argue that this is logically the
> > > right thing to do (even though the extra call is not needed to shut the
> > > LED off).
> > >
> > > Signed-off-by: Micha?? K??pie?? <kernel@kempniu.pl>
> > > ---
> > > This is a follow-up to a recent patch, "platform/x86: fujitsu-laptop:
> > > use brightness_set_blocking for LED-setting callbacks" and thus needs
> > > the latter to be applied first (currently it is already applied in
> > > testing).
> > >
> > > Instead of sticking "if (ret < 0) return ret;" in two branches I decided
> > > to restructure logolamp_set() for improved clarity and also to make it
> > > resemble logolamp_get() a bit more.
> > >
> > >  drivers/platform/x86/fujitsu-laptop.c | 20 ++++++++++++--------
> > >  1 file changed, 12 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
> > > index b725a907a91f..12f7a8346dd0 100644
> > > --- a/drivers/platform/x86/fujitsu-laptop.c
> > > +++ b/drivers/platform/x86/fujitsu-laptop.c
> > > @@ -271,15 +271,19 @@ static int call_fext_func(int cmd, int arg0, int arg1, int arg2)
> > >  static int logolamp_set(struct led_classdev *cdev,
> > >                                enum led_brightness brightness)
> > >  {
> > > -       if (brightness >= LED_FULL) {
> > > -               call_fext_func(FUNC_LEDS, 0x1, LOGOLAMP_POWERON, FUNC_LED_ON);
> > > -               return call_fext_func(FUNC_LEDS, 0x1, LOGOLAMP_ALWAYS, FUNC_LED_ON);
> > > -       } else if (brightness >= LED_HALF) {
> > > -               call_fext_func(FUNC_LEDS, 0x1, LOGOLAMP_POWERON, FUNC_LED_ON);
> > > -               return call_fext_func(FUNC_LEDS, 0x1, LOGOLAMP_ALWAYS, FUNC_LED_OFF);
> > > -       } else {
> > > -               return call_fext_func(FUNC_LEDS, 0x1, LOGOLAMP_POWERON, FUNC_LED_OFF);
> > 
> > > +       int ret, poweron = FUNC_LED_OFF, always = FUNC_LED_OFF;
> > > +
> > > +       if (brightness >= LED_HALF) {
> > > +               poweron = FUNC_LED_ON;
> > > +               if (brightness >= LED_FULL)
> > > +                       always = FUNC_LED_ON;
> > >         }
> > 
> > But if you set ON by default the above could be written like
> > 
> >     if (brightness < LED_FULL)
> >         always = FUNC_LED_OFF;
> > 
> >     if (brightness < LED_HALF)
> >         poweron = FUNC_LED_OFF;
> 
> Ah, neat, thanks.  Jonathan, assuming you also like this, I will later
> submit v2 using this approach.

Yes, I like this.  It does in fact make the intent clearer.

The subsequent suggestion to split the "int ret, poweron ..." line is also
worthwhile since it makes one less likely to miss the declaration of "ret" at
the start.

Regards
  jonathan

      parent reply	other threads:[~2017-01-07  1:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-05 13:11 [PATCH] platform/x86: fujitsu-laptop: rework logolamp_set() to properly handle errors Michał Kępień
2017-01-05 14:08 ` Jonathan Woithe
2017-01-06 15:25 ` Andy Shevchenko
2017-01-06 19:24   ` Michał Kępień
2017-01-06 20:48     ` Andy Shevchenko
2017-01-07  1:01     ` Jonathan Woithe [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=20170107010124.GA4631@marvin.atrad.com.au \
    --to=jwoithe@just42.net \
    --cc=andy.shevchenko@gmail.com \
    --cc=dvhart@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox