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
next prev parent 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 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.