public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@infradead.org>
To: Jonathan Woithe <jwoithe@just42.net>
Cc: Micha?? K??pie?? <kernel@kempniu.pl>,
	Andy Shevchenko <andy@infradead.org>,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 04/10] platform/x86: fujitsu-laptop: rework backlight power synchronization
Date: Mon, 1 May 2017 09:17:43 -0700	[thread overview]
Message-ID: <20170501161743.GC29387@fury> (raw)
In-Reply-To: <20170501133245.GD25546@marvin.atrad.com.au>

On Mon, May 01, 2017 at 11:02:45PM +0930, Jonathan Woithe wrote:
> On Mon, Apr 24, 2017 at 03:33:28PM +0200, Micha?? K??pie?? wrote:
> > fujitsu-laptop registers two ACPI drivers: one for ACPI device FUJ02B1
> > enabling backlight control and another for ACPI device FUJ02E3 which
> > handles various other stuff (hotkeys, LEDs, etc.)  So far, these two
> > drivers have been entangled by calls to fext_backlight() (previously
> > known as call_fext_func()) in the backlight part of the module which use
> > module-wide data managed by the other part of the module and accesses to
> > the backlight device from within acpi_fujitsu_laptop_add().  This
> > entaglement can be solved by storing an independently fetched ACPI
> > handle to the FUJ02E3 device inside the data structure managed by the
> > backlight part of the module.
> > 
> > Add a field to struct fujitsu_bl for storing a handle to the FUJ02E3
> > ACPI device.  Make fext_backlight() calls use that handle instead of the
> > one from struct fujitsu_laptop.  Move backlight power synchronization
> > from acpi_fujitsu_laptop_add() to fujitsu_backlight_register().
> > 
> > This makes the bl_device field of struct fujitsu_bl redundant, so remove
> > it.
> > 
> > Signed-off-by: Micha?? K??pie?? <kernel@kempniu.pl>
> > ---
> >  drivers/platform/x86/fujitsu-laptop.c | 27 ++++++++++++---------------
> >  1 file changed, 12 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
> > index ea3210ee83ec..5f6b34a97348 100644
> > --- a/drivers/platform/x86/fujitsu-laptop.c
> > +++ b/drivers/platform/x86/fujitsu-laptop.c
> > @@ -131,9 +131,9 @@
> >  /* Device controlling the backlight and associated keys */
> >  struct fujitsu_bl {
> >  	acpi_handle handle;
> > +	acpi_handle fext_handle;
> 
> This is the extra "handle" field I eluded to in my comment about an earlier
> part of this patch series.  The end result is two "handle" fields: one whose
> job is obvious (fext_handle) and one whose name in no way reflects what it
> might be used for (handle).  One could of course adopt the view that any
> unqualified handle is a generic acpi handle, but I like the clarification
> which comes with the additional suffix.  Perhaps "acpi_handle" is too
> generic and I'm certainly not opposed to the use of something more specific. 
> However, IMHO leaving it as "handle" seems like an unnecessary obfuscation
> without much gain.

Yeah, that's a fair criticism. Naming is hard. I can see the argument for
"handle" is for the system in general, "fext_handle" is for this specific subset
of functionality". The alternative appears to be "plt_handle", "fuj_handle",
"main_handle", or "hk_led_etc_handle ;-)" which honestly doesn't add any new
information or is just silly. So, if you want to prefix handle, go ahead and do
so, but I don't think it's a big deal.

> 
> This change reinforces the shift away from ACPI drivers linked to specific
> ACPI devices, and towards a focus on the driver's functionality (backlight
> and "various other stuff").  With the evolution of the hardware I think this
> makes sense.  While the "other stuff" still needs a driver, the backlight
> component is not always needed.  The case for separation therefore makes
> sense.
> 
> As a point of discussion though, since the backlight driver needs access to
> both FUJ02B1 and FUJ02E3, should we consider rolling both ACPI drivers into
> one?  Aside from conceptual neatness and perhaps a small runtime memory
> footprint saving in the event that no backlight control functionality need
> be provided by fujitsu-laptop, is there a whole lot to be gained through the
> use of two separate drivers?

This on the other hand is something we need to consider carefully. I'd like to
hear from Michal on this before I comment further.

-- 
Darren Hart
VMware Open Source Technology Center

  reply	other threads:[~2017-05-01 16:17 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-24 13:33 [PATCH 00/10] fujitsu-laptop: use device-specific data instead of module-wide globals Michał Kępień
2017-04-24 13:33 ` [PATCH 01/10] platform/x86: fujitsu-laptop: introduce fext_*() helper functions Michał Kępień
2017-05-01 13:13   ` Jonathan Woithe
2017-05-02 13:24     ` Michał Kępień
2017-04-24 13:33 ` [PATCH 02/10] platform/x86: fujitsu-laptop: shorten names of acpi_handle fields Michał Kępień
2017-05-01 13:19   ` Jonathan Woithe
2017-05-01 16:09     ` Darren Hart
2017-04-24 13:33 ` [PATCH 03/10] platform/x86: fujitsu-laptop: explicitly pass ACPI handle to call_fext_func() Michał Kępień
2017-04-24 13:33 ` [PATCH 04/10] platform/x86: fujitsu-laptop: rework backlight power synchronization Michał Kępień
2017-05-01 13:32   ` Jonathan Woithe
2017-05-01 16:17     ` Darren Hart [this message]
2017-04-24 13:33 ` [PATCH 05/10] platform/x86: fujitsu-laptop: distinguish current uses of device-specific data Michał Kępień
2017-05-01 13:40   ` Jonathan Woithe
2017-04-24 13:33 ` [PATCH 06/10] platform/x86: fujitsu-laptop: allocate struct fujitsu_bl in acpi_fujitsu_bl_add() Michał Kępień
2017-04-24 13:33 ` [PATCH 07/10] platform/x86: fujitsu-laptop: use device-specific data in backlight code Michał Kępień
2017-04-24 13:33 ` [PATCH 08/10] platform/x86: fujitsu-laptop: allocate struct fujitsu_laptop in acpi_fujitsu_laptop_add() Michał Kępień
2017-04-24 13:33 ` [PATCH 09/10] platform/x86: fujitsu-laptop: use device-specific data in LED-related code Michał Kępień
2017-04-24 13:33 ` [PATCH 10/10] platform/x86: fujitsu-laptop: use device-specific data in remaining module code Michał Kępień
2017-05-01 13:05 ` [PATCH 00/10] fujitsu-laptop: use device-specific data instead of module-wide globals Jonathan Woithe
2017-05-02 13:21   ` Michał Kępień
2017-05-04 23:40     ` Jonathan Woithe
2017-05-05 16:15       ` Darren Hart
2017-05-06 12:31         ` Michał Kępień
2017-05-06 12:45           ` Michał Kępień
2017-05-06 14:21             ` Andy Shevchenko
2017-05-06 14:23               ` Andy Shevchenko
2017-05-08 16:01             ` Darren Hart
2017-05-09  9:35               ` Michał Kępień
2017-05-09 12:13                 ` Jonathan Woithe
2017-05-09 16:47                 ` Darren Hart
2017-05-09 21:24                   ` Rafael J. Wysocki
2017-05-11 13:52                     ` Michał Kępień
2017-05-11 14:37                       ` Rafael J. Wysocki
2017-05-11 15:38                         ` Darren Hart
2017-05-11 13:40                   ` Michał Kępień
2017-05-15 23:27                     ` Darren Hart
2017-05-16  0:06                       ` Jonathan Woithe
2017-05-16  6:40                         ` Michał Kępień
2017-05-15 23:56                     ` 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=20170501161743.GC29387@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox