diff options
| author |   Michał Kępień <kernel@kempniu.pl> | 2017-05-19 09:44:45 +0200 |
|---|---|---|
| committer |   Darren Hart (VMware) <dvhart@infradead.org> | 2017-06-03 12:04:29 -0700 |
| commit | ca0d9eab0fb5b92c94de049241d639c2db66c3a6 (patch) | |
| tree | ace8fce8b0ac39135f337b53e9f4def9adf6fa7c /drivers/platform/x86/fujitsu-laptop.c | |
| parent | platform/x86: fujitsu-laptop: allocate fujitsu_laptop in acpi_fujitsu_laptop_add() (diff) | |
| download | linux-dev-ca0d9eab0fb5b92c94de049241d639c2db66c3a6.tar.xz linux-dev-ca0d9eab0fb5b92c94de049241d639c2db66c3a6.zip | |
platform/x86: fujitsu-laptop: track the last instantiated FUJ02E3 ACPI device
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.) In a perfect world,
private data used by each of these drivers would be neatly encapsulated
in a structure specific to a given driver instance. Sadly, firmware
present on some Fujitsu laptops makes that impossible by exposing
backlight power control (which is what the FUJ02B1 ACPI device should
take care of) through the FUJ02E3 ACPI device. This means the backlight
driver needs a way to access an ACPI device it is not bound to. When
the backlight driver is extracted into a separate module, it will not be
able to rely on a module-wide variable any more and such access will
happen through an API exposed by fujitsu-laptop.
For all known firmwares out in the wild, it seems that whenever the
FUJ02B1 ACPI device is present, it is always accompanied by a single
instance of the FUJ02E3 ACPI device. We could independently grab an
ACPI handle to the FUJ02E3 ACPI device from the backlight driver, but
that would require using a hardcoded absolute path to that ACPI device,
which is subject to change. It is easier to simply store a module-wide
pointer to the last (most likely only) FUJ02E3 ACPI device found, make
the aforementioned API use it and cover our bases by warning the user if
firmware exposes multiple FUJ02E3 ACPI devices.
Introducing this pointer in advance allows us to get rid of the
acpi_handle field of struct fujitsu_bl and also enables a bit more
step-by-step migration to a device-specific implementation of
call_fext_func().
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
Reviewed-by: Jonathan Woithe <jwoithe@just42.net>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Diffstat (limited to 'drivers/platform/x86/fujitsu-laptop.c')
| -rw-r--r-- | drivers/platform/x86/fujitsu-laptop.c | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c index 3916f0ae59f3..21bd60afea75 100644 --- a/drivers/platform/x86/fujitsu-laptop.c +++ b/drivers/platform/x86/fujitsu-laptop.c @@ -155,6 +155,7 @@ struct fujitsu_laptop { }; static struct fujitsu_laptop *fujitsu_laptop; +static struct acpi_device *fext; #ifdef CONFIG_FUJITSU_LAPTOP_DEBUG static u32 dbg_level = 0x03; @@ -788,6 +789,9 @@ static int acpi_fujitsu_laptop_add(struct acpi_device *device) if (!priv) return -ENOMEM; + WARN_ONCE(fext, "More than one FUJ02E3 ACPI device was found. Driver may not work as intended."); + fext = device; + fujitsu_laptop = priv; fujitsu_laptop->acpi_handle = device->handle; sprintf(acpi_device_name(device), "%s", |