We have two memory leaks. If guid_already_parsed returned true, we leak
the wmi_block. If wmi_create_device failed, we leak the device.

Simplify the logic and fix both of them.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Mario Limonciello <mario_limonciello@dell.com>
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

WMI is logically a bus: the WMI driver binds to an ACPI node (or
more than one), and each instance of the WMI driver enumerates its
children and hopes that drivers will attach to the children that are
useful.

This patch gives WMI a driver model bus type and the ability to
match to drivers. The bus itself is a device in the new "wmi_bus"
class, and all of the individual WMI devices are slotted into the
device hierarchy correctly.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Mario Limonciello <mario_limonciello@dell.com>
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Currently we free all devices when we detach from any ACPI node.
Instead, keep track of which node WMI devices are attached to and
free them only as needed. While we are at it, match up notifications
with the device they came from correctly.

This will make our behavior more straightforward on systems with
more than one WMI node in the ACPI tables (e.g. the Dell XPS 13
9350).

This also adds a warning when GUIDs are not unique.

NB: The guid_string parameter in guid_already_parsed was a
little-endian binary GUID, not a string.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Mario Limonciello <mario_limonciello@dell.com>
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Rearrange acpi_wmi_add to use Linux's error handling conventions.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Mario Limonciello <mario_limonciello@dell.com>
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

We will need the device to convert to a bus architecture and bind WMI to
the platform device.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Mario Limonciello <mario_limonciello@dell.com>
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

WMI is just a driver. There is no need to announce when it is loaded.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Mario Limonciello <mario_limonciello@dell.com>
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

According to Mario at Dell, the DELLABC6 device should not be used on a
Linux system. It also conflicts with Intel-HID and its interactions with
Network Manager. Document that we are aware of the device, but that we
are intentionally ignoring it.
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
[dvhart: New commit message and minor comment wording fixes]
Cc: Mario Limonciello <mario_limonciello@dell.com>
Cc: "Pali Rohár" <pali.rohar@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

This is based on Mario's explanation and observation of my laptop.
Suggested-by: N"Pali Rohár" <pali.rohar@gmail.com>
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Cc: Mario Limonciello <mario_limonciello@dell.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

The hotkey table is 0xb2, add a comment for clarity.
Suggested-by: NDarren Hart <dvhart@infradead.org>
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

To avoid using module-wide data in remaining module code, employ
acpi_driver_data() and dev_get_drvdata() to fetch device-specific data
to work on in each function.  This makes the input local variables in
hotkey-related callbacks and the module-wide struct fujitsu_laptop
redundant, so remove them.  Adjust whitespace to make checkpatch happy.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

In order to perform their duties, all LED callbacks need a pointer to
the struct acpi_device representing the FUJ02E3 ACPI device.  To limit
the use of the module-wide pointer, the same pointer should be extracted
from data that gets passed to LED callbacks as arguments.  However, LED
core does not currently support supplying driver-specific pointers to
struct led_classdev callbacks, so the latter have to be implemented a
bit differently than backlight device callbacks and platform device
attribute callbacks.  As the FUJ02E3 ACPI device is the parent device of
all LED class devices registered by fujitsu-laptop, struct acpi_device
representing the former can be extracted by following the parent link
present inside the struct device belonging to the struct led_classdev
passed as an argument to each LED callback.

To get rid of module-wide structures defining LED class devices,
allocate them dynamically using devm_kzalloc() and initialize them in
acpi_fujitsu_laptop_leds_register().
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Prepare for not using module-wide data in call_fext_func() by explicitly
passing it a pointer to struct acpi_device while still using a
module-wide pointer in each call.

Doing this enables call_fext_func() to fetch the ACPI handle from its
argument, making the acpi_handle field of struct fujitsu_laptop useless,
so remove that field.  While we are at it, the dev field of the same
structure is assigned in acpi_fujitsu_laptop_add() but not used for
anything, so remove it as well.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

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: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Only allocate memory for struct fujitsu_laptop when the FUJ02E3 ACPI
device is present.  Use devm_kzalloc() for allocating memory to simplify
cleanup.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

To prevent using module-wide data in backlight-related code, employ
acpi_driver_data() and bl_get_data() where possible to fetch
device-specific data to work on in each function.  This makes the input
local variable in acpi_fujitsu_bl_notify() and the acpi_handle field of
struct fujitsu_bl redundant, so remove them.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Only allocate memory for struct fujitsu_bl when the FUJ02B1 ACPI device
is present.  Use devm_kzalloc() for allocating memory to simplify
cleanup.

Due to the fact that the power property of the backlight device created
by the backlight driver is accessed from acpi_fujitsu_laptop_add(),
pointer to the allocated memory will remain stored in a module-wide
variable until the backlight driver is extracted into a separate module.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

In portions of the driver which use device-specific data, rename local
variables from fujitsu_bl and fujitsu_laptop to priv in order to clearly
distinguish these parts from code that uses module-wide data.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Devices with the intel_cht_int33fe ACPI device use a max17047 fuel-gauge
combined with a bq24272i charger, in order for the fuel-gauge driver to
correctly display charging / discharging status it needs to know which
charger is supplying the battery.

This commit sets the supplied-from device property to the name of the
bq24272i charger for this.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The function is currently not used, however it is part of the API and
might be used in the future. Adding the attribute fixes the following
warning when building with clang:

    drivers/platform/x86/intel_pmc_ipc.c:189:18: error: unused function
        'ipc_data_readb' [-Werror,-Wunused-function]
Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Don't simply throw this to userspace via the sparse_keymap (which does not
have a mapping for scancode 1), as this causes KEY_UNKNOWN to be emitted,
which is a nuisance and of no use at all (it is not the right way to expose
this ACPI event to userspace, anyway, and the original intention of the commit
which added this (cfee5d63) was only to suppress
an unhandled event log message).
Signed-off-by: NHao Wei Tee <angelsl@angelsl.xyz>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

A readonly sysfs property must not have a 'store' function:

drivers/platform/x86/ideapad-laptop.c:438:16: error: 'touchpad_store' defined but not used [-Werror=unused-function]

We can either comment it out or remove the function entirely,
without a good reason one or or another I picked the second option.

Fixes: 7f363145 ("platform/x86: ideapad-laptop: Switch touchpad attribute to be RO")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The latest Topstar BIOS updates (109_931P) advertise the "TPS0001"
device id by default, preventing the topstar-laptop module from being
loaded automatically.
Signed-off-by: NGuillaume Douézan-Grard <gdouezangrard@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

PEAQ is a new European OEM, I've bought one of their 2-in-1 x86 devices,
which is actually quite a nice device. Under Windows it has Dolby
software for "better" sound and you can select different equalizer
presets using a special button.

This WMI interface for this button is not really nice, as it does not do
notifies (it really does not I triple checked), but since I had already
figured out the entire WMI interface for this I decided to go the full
mile anyway and implement a WMI based input driver for this using
input_polldev since, well, we need to poll.

This commit adds support for this button making it report KEY_SOUND
input events. KEY_SOUND is already used in various places to switch
sound into theatre mode and things like that so it seems appropriate
here.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
[dvhart: minor declaration ordering and commit log typo fixes]
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

As per discussion [1] there are only few users of module_param_call() in
kernel which prevent to read module parameters back.

It thinkpad_acpi driver there is even no method do so. Thus, for now,
add just a comment to explain why 0 is used as permissions in
module_param_call().

[1]: https://patchwork.ozlabs.org/patch/713245/

Cc: Richard Weinberger <richard.weinberger@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

There is no point to keep string literal split. It even makes slightly
harder to maintain and debug.

Join string literals back to be oneliners.

While here, print negative error without changing a sign as it is a
common pattern in the kernel.

Other than above there were no functional changes intended.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

Add touchscreen info for the GP-electronic T701 tablet.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Use memdup_user_nul() helper instead of open-coding to simplify the
code.
Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

For now let's restrict touchpad attribute to be read only.
We might revisit this in the future though.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Lenovo Yoga (many variants: Yoga, Yoga2 Pro, Yoga2 13, Yoga3 Pro, Yoga 3
14, etc) has multiple modles that are a hybrid laptop, working in laptop
mode as well as tablet mode.

Currently, there is no easy interface to determine the touchpad status,
which in case of the Yoga family of machines, can also be useful to
assume tablet mode status.

Note: The ideapad-laptop driver does not provide a SW_TABLET_MODE either.

For a detailed discussion  on why we want either of the interfaces,
please see:
https://bugs.launchpad.net/onboard/+bug/1366421/comments/43

This patch adds a sysfs interface for read/write access under:
/sys/bus/platform/devices/VPC2004\:00/touchpad_mode
Signed-off-by: NRitesh Raj Sarraf <rrs@debian.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

SILEAD_DMI provides platform specific data for the TOUCHSCREEN_SILEAD
driver. Make this explicitly clear in the Kconfig depends. Remove
INPUT as this is implied by TOUCHSCREEN_SILEAD.
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Andy Shevchenko <andy@infradead.org>
Cc: Jean Delvare <jdelvare@suse.de>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

some laptops, for example ASUS UX330UAK, have brocken als_get function
but working als_set funktion. In this case, ALS will stay turned off.

             Method (WMNB, 3, Serialized)
            {
	    ...
               If (Local0 == 0x53545344)
                {
		...
                    If (IIA0 == 0x00050001)
                    {
                        If (!ALSP)
                        {
                            Return (0x02)
                        }

                        Local0 = (GALS & 0x10)    <<<---- bug,
                                                    should be: (GALS () & 0x10)
                        If (Local0)
                        {
                            Return (0x00050001)
                        }
                        Else
                        {
                            Return (0x00050000)
                        }
                    }

             .....
                If (Local0 == 0x53564544)
                {
		...
                    If (IIA0 == 0x00050001)
                    {
                        Return (ALSC (IIA1))
                    }

                  ......
                    Method (GALS, 0, NotSerialized)
                    {
                        Local0 = Zero
                        Local0 |= 0x20
                        If (ALAE)
                        {
                            Local0 |= 0x10
                        }

                        Local1 = 0x0A
                        Local1 <<= 0x08
                        Local0 |= Local1
                        Return (Local0)
                    }

Since it works without problems on Windows I assume ASUS WMI driver for Win
never trying to get ALS state, and instead it is setting it by default to ON.

This patch will do the same. Turn ALS on by default.
Signed-off-by: NOleksij Rempel <linux@rempel-privat.de>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The cpufv sysfs file is defined as readable by anyone even if the
attribute does not have a show function. The result of every read is an
IO error. This file should be write only.
Signed-off-by: NJérémy Lefaure <jeremy.lefaure@lse.epita.fr>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The 98d610c3 patch was introduced since v4.11-rc1 that it causes
that the accelerometer input device will not be created on workable
machines because the HID string comparing logic is wrong.

And, the patch doesn't prevent that the accelerometer input device
be created on the machines that have no BST0001. That's because
the acpi_get_devices() returns success even it didn't find any
match device.

This patch fixed the HID string comparing logic of BST0001 device.
And, it also makes sure that the acpi_get_devices() returns
acpi_handle for BST0001.

Fixes: 98d610c3 ("acer-wmi: setup accelerometer when machine has appropriate notify event")
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=193761Reported-by: NSamuel Sieb <samuel-kbugs@sieb.net>
Signed-off-by: N"Lee, Chun-Yi" <jlee@suse.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Like other Lenovo models the IdeaPad V310-15ISK does not have an hw
rfkill switch. This results in hard-blocked radios after boot, resulting
in always blocked radios rendering them unusable.

Add the IdeaPad V310-15ISK to the no_hw_rfkill DMI list and allows using
the built-in radios.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

To maintain the uniformity in accessing GCR registers, this patch
modifies the S0ix counter read function to use GCR address base
instead of ipc address base.
Signed-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Reviewed-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Tested-by: NShanth Murthy <shanth.murthy@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

iTCO_wdt driver need access to PMC_CFG GCR register to modify the
noreboot setting. Currently, this is done by passing PMC_CFG reg
address as memory resource to watchdog driver and allowing it directly
modify the PMC_CFG register. But currently PMC driver also has
requirement to memory map the entire GCR register space in this driver.
This causes mem request failure in watchdog driver. So this patch fixes
this issue by adding API to update noreboot flag and passes them
to watchdog driver via platform data.
Signed-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

This patch adds API's to read/write/update PMC GC registers.
PMC dependent devices like iTCO_wdt, Telemetry has requirement
to acces GCR registers. These API's can be used for this
purpose.
Signed-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

According to Broxton APL spec, PMC MIMO resources for Global Control
Registers(GCR) are located at 4K(0x1000) offset from IPC base address.
In this driver, PLAT_RESOURCE_GCR_OFFSET macro defines the offset of GCR
region base address from IPC base address and its current value of
0x1008 is incorrect because it points to location for PMC_CFG register
and not the GCR base address itself.

GCR Base = IPC1 Base + 0x1000.

This patch fixes this offset issue.
Signed-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

When changing keyboard backlight state on new Dell laptops, firmware
expects a new timeout AC value filled in Set New State SMBIOS call.

Without it any change of keyboard backlight state on new Dell laptops
fails. And user can see following error message in dmesg:

  dell_laptop: Setting old previous keyboard state failed
  leds dell::kbd_backlight: Setting an LED's brightness failed (-6)

This patch adds support for retrieving current timeout AC values and also
updating them. Current timeout value in sysfs is displayed based on current
AC status, like current display brightness value.

Detection if Dell laptop supports or not new timeout AC settings is done by
checking existence of Keyboard Backlight with AC SMBIOS token (0x0451).
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Acked-by: NMario Limonciello <mario.limonciello@dell.com>
Tested-by: NArcadiy Ivanov <arcadiy@ivanov.biz>
[andy: fixed merge conflict with defined constants]
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Here, This patch is to handle a return error from dell_get_intensity.
This change is done using Coccinelle.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>