linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@infradead.org>
To: "Michał Kępień" <kernel@kempniu.pl>
Cc: Jonathan Woithe <jwoithe@just42.net>,
	Rafael Wysocki <rjw@rjwysocki.net>,
	Andy Shevchenko <andy@infradead.org>,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/10] fujitsu-laptop: use device-specific data instead of module-wide globals
Date: Mon, 8 May 2017 09:01:02 -0700	[thread overview]
Message-ID: <20170508160102.GE17700@fury> (raw)
In-Reply-To: <20170506124516.GA1075@kmp-mobile.hq.kempniu.pl>

On Sat, May 06, 2017 at 02:45:16PM +0200, Michał Kępień wrote:
> > Just to make sure we are all on the same page here, choosing the "two
> > separate modules, each with one driver for one ACPI device" approach
> > would mean ending up with two modules:
> > 
> >   - fujitsu-laptop, binding to the FUJ02E3 ACPI device, handling
> >     everything _except_ backlight,
> > 
> >   - fujitsu-backlight, binding to the FUJ02B1 ACPI device, handling
> >     backlight and depending on fujitsu-laptop.
> > 
> > We would need to export one function from fujitsu-laptop, namely
> > fext_backlight().  I understand this would require creating a separate
> > header file which would then be included in fujitsu-backlight.
> > 
> > fext_backlight() causes the FUNC method of the FUJ02E3 ACPI device to be
> > called.  This method is marked as Serialized, which AFAIU means we do
> > not need a separate lock in kernel code because all calls to this method
> > are implicitly serialized by firmware itself.
> > 
> > I do not see anything "unnatural" in this approach, but I would love to
> > be corrected if I am wrong.
> 
> To be fair, one thing that may be "unnatural" with this approach is that
> even though fujitsu-backlight would depend on fujitsu-laptop, it would
> still have to get a handle to FUJ02E3 using:
> 
>     acpi_get_handle(NULL, "\\_SB.FEXT", ...)
>     
> because call_fext_func() - and thus fext_backlight() - needs to be
> passed a handle to FUJ02E3 and the two ACPI devices (FUJ02B1 handled by
> fujitsu-backlight and FUJ02E3 handled by fujitsu-laptop) are not related
> from the perspective of the ACPI device hierarchy.  Unless there is a
> better way of implementing this, in which case I am open to suggestions.

At a high level, I would consider the handle to be private data which should be
encapsulated in fujitsu_laptop. Or... where is FEXT in the ACPI hierarchy
relative to FUJ02E3?

Assuming FEXT is below FUJ02E3, the we appear to be making an assumption that
there is only one FUJ02E3 on the system. While I think this is perfectly
reasonable, it does contradict the argumentation from some of the other patches
in this series.

If FEXT is not below fujitsu laptop... then it is a shared function which either
one of them can own and serialize (or not if fw indeed handles that).

Either way, the owning driver should abstract away the private data and present
an interface the other can use with only the "public" information.

I suggest investigating the various mechanisms Andy pointed at and revisiting
this after that.

-- 
Darren Hart
VMware Open Source Technology Center

  parent reply	other threads:[~2017-05-08 16:01 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
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 [this message]
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=20170508160102.GE17700@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 \
    --cc=rjw@rjwysocki.net \
    /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 NNTP newsgroup(s).