Just like we avoid specifying actual block devices like sda for fdisk
and dd examples, we should not specify specific thermal zones here.

On the platform I was testing on, zone0 was acpitz, and zone1 was for
this acerhdf driver.  Make the printk such that it won't work with a
blind cut-and-paste, and force the user to determine which zone is
correct for this driver.

Cc: Peter Feuerer <peter@piie.net>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NPeter Feuerer <peter@piie.net>

On systems with ACPI instantiated i2c-clients, normally there is 1 fw_node
per i2c-device and that fw-node contains 1 I2cSerialBus resource for that 1
i2c-device.

But in some rare cases the manufacturer has decided to describe multiple
i2c-devices in a single ACPI fwnode with multiple I2cSerialBus resources.

An earlier attempt to fix this in the i2c-core resulted in a lot of extra
code to support this corner-case.

This commit introduces a new i2c-multi-instantiate driver which fixes this
in a different way. This new driver can be built as a module which will
only loaded on affected systems.

This driver will instantiate a new i2c-client per I2cSerialBus resource,
using the driver_data from the acpi_device_id it is binding to to tell it
which chip-type (and optional irq-resource) to use when instantiating.

Note this driver depends on a platform device being instantiated for the
ACPI fwnode, see the i2c_multi_instantiate_ids list of ACPI device-ids in
drivers/acpi/scan.c: acpi_device_enumeration_by_parent().
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Not only silead touchscreens need some extra info not available in the
ACPI tables to work properly. X86 devices with a Chipone ICN8505 chip also
need some DMI based extra configuration.

There is no reason to have separate dmi config code per touchscreen
controller vendor. This commit renames silead_dmi to a more generic
touchscreen_dmi name (and Kconfig option) in preparation of adding
info for tablets with an ICN8505 based touchscreen.

Note there are no functional changes all code changes are limited to
removing references to silead where these are no longer applicable.
Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

As files move around, their previous links break. Fix the
references for them.
Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: NJonathan Corbet <corbet@lwn.net>

The driver will not probe unless bq24190 is loaded, so
making it a dependency.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If DELL_WMI "select"s DELL_SMBIOS, the DELL_SMBIOS dependencies are
ignored and it is still possible to end up with unmet direct
dependencies.

Change the select to a depends on.
Tested-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

If DELL_WMI "select"s DELL_SMBIOS, the DELL_SMBIOS dependencies are
ignored and it is still possible to end up with unmet direct
dependencies.

Change the select to a depends on.
Tested-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

As reported by Randy Dunlap:
>> WARNING: unmet direct dependencies detected for DELL_SMBIOS
>>   Depends on [m]: X86 [=y] && X86_PLATFORM_DEVICES [=y]
>>	&& (DCDBAS [=m] ||
>> DCDBAS [=m]=n) && (ACPI_WMI [=n] || ACPI_WMI [=n]=n)
>>   Selected by [y]:
>>   - DELL_LAPTOP [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y]
>> && DMI [=y]
>> && BACKLIGHT_CLASS_DEVICE [=y] && (ACPI_VIDEO [=n] ||
>>	ACPI_VIDEO [=n]=n)
>> && (RFKILL [=n] || RFKILL [=n]=n) && SERIO_I8042 [=y]
>>

Right now it's possible to set dell laptop to compile in but this
causes dell-smbios to compile in which breaks if dcdbas is a module.

Dell laptop shouldn't select dell-smbios anymore, but depend on it.

Fixes: 32d7b19b (platform/x86: dell-smbios: Resolve dependency error on DCDBAS)
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

As reported by Randy Dunlap:
>> WARNING: unmet direct dependencies detected for DELL_SMBIOS
>>   Depends on [m]: X86 [=y] && X86_PLATFORM_DEVICES [=y]
>>	&& (DCDBAS [=m] ||
>> DCDBAS [=m]=n) && (ACPI_WMI [=n] || ACPI_WMI [=n]=n)
>>   Selected by [y]:
>>   - DELL_LAPTOP [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y]
>> && DMI [=y]
>> && BACKLIGHT_CLASS_DEVICE [=y] && (ACPI_VIDEO [=n] ||
>>	ACPI_VIDEO [=n]=n)
>> && (RFKILL [=n] || RFKILL [=n]=n) && SERIO_I8042 [=y]
>>

Right now it's possible to set dell laptop to compile in but this
causes dell-smbios to compile in which breaks if dcdbas is a module.

Dell laptop shouldn't select dell-smbios anymore, but depend on it.

Fixes: 32d7b19b (platform/x86: dell-smbios: Resolve dependency error on DCDBAS)
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

mlx-platform does not provide a bus number to i2c-mlxcpld, assuming it
is always one. On some x86 systems, other i2c drivers may probe before
i2c-mlxcpld, causing bus one to be busy.

Make mlx-platform determine which adapter number is free prior to
activating i2c-mlxpld, adjusting the mux base numbers accordingly.
Update the mlxreg-hotplug pdata similarly.

This adds an explicit mlx-platform build dependency on I2C, update the
Kconfig accordingly. Add the missing REGMAP dependency while we're at
it.
Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
[dvhart: Rewrite commit message more concisely]
[dvhart: Add build dependencies]
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Similarly to DCDBAS for DELL_SMBIOS_SMM, if DELL_SMBIOS_WMI is enabled,
DELL_SMBIOS becomes dependent on ACPI_WMI. Update the depends lines to
prevent a configuration where DELL_SMBIOS=y and either backend
dependency =m. Update the comment accordingly.

Cc: Mario Limonciello <mario.limonciello@dell.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Similarly to DCDBAS for DELL_SMBIOS_SMM, if DELL_SMBIOS_WMI is enabled,
DELL_SMBIOS becomes dependent on ACPI_WMI. Update the depends lines to
prevent a configuration where DELL_SMBIOS=y and either backend
dependency =m. Update the comment accordingly.

Cc: Mario Limonciello <mario.limonciello@dell.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

When the DELL_SMBIOS_SMM backend is enabled, the DELL_SMBIOS symbol
depends on DELL_DCDBAS, and we must avoid the situation where
DELL_SMBIOS=y and DCDBAS=m.

Adding the conditional dependency to DELL_SMBIOS such as:

depends !DELL_SMBIOS_SMM || (DCDBAS || DCDBAS=n)

results in the Kconfig tooling complaining about a circular dependency,
although it appears to work in practice.

Avoid the errors by simplifying the dependency and forcing DELL_SMBIOS
to be <= DCDBAS if DCDBAS is enabled (thanks to Greg KH for the
suggestion).

Cc: Mario.Limonciello@dell.com
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Avoid accidental configurations by setting default y for DELL_SMBIOS
backends. Avoid this impacting the default build size, by making them
dependent on DELL_SMBIOS, so they only appear when DELL_SMBIOS is
manually selected, or by DELL_LAPTOP or DELL_WMI.

While DELL_SMBIOS does have a prompt, it does not have any dependencies.
Keeping DELL_SMBIOS visible, despite being "select"ed by DELL_LAPTOP and
DELL_WMI, is a deliberate choice to provide context for the WMI and SMM
backends, which would otherwise appear to float without context within
the menu.
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Some race conditions were raised due to dell-smbios and its backends
not being ready by the time that a consumer would call one of the
exported methods.

To avoid this problem, guarantee that all initialization has been
done by linking them all together and running init for them all.

As part of this change the Kconfig needs to be adjusted so that
CONFIG_DELL_SMBIOS_SMM and CONFIG_DELL_SMBIOS_WMI are boolean
rather than modules.

CONFIG_DELL_SMBIOS is a visually selectable option again and both
CONFIG_DELL_SMBIOS_WMI and CONFIG_DELL_SMBIOS_SMM are optional.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
[dvhart: Update prompt and help text for DELL_SMBIOS_* backends]
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

When the DELL_SMBIOS_SMM backend is enabled, the DELL_SMBIOS symbol
depends on DELL_DCDBAS, and we must avoid the situation where
DELL_SMBIOS=y and DCDBAS=m.

Adding the conditional dependency to DELL_SMBIOS such as:

depends !DELL_SMBIOS_SMM || (DCDBAS || DCDBAS=n)

results in the Kconfig tooling complaining about a circular dependency,
although it appears to work in practice.

Avoid the errors by simplifying the dependency and forcing DELL_SMBIOS
to be <= DCDBAS if DCDBAS is enabled (thanks to Greg KH for the
suggestion).

Cc: Mario.Limonciello@dell.com
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Avoid accidental configurations by setting default y for DELL_SMBIOS
backends. Avoid this impacting the default build size, by making them
dependent on DELL_SMBIOS, so they only appear when DELL_SMBIOS is
manually selected, or by DELL_LAPTOP or DELL_WMI.

While DELL_SMBIOS does have a prompt, it does not have any dependencies.
Keeping DELL_SMBIOS visible, despite being "select"ed by DELL_LAPTOP and
DELL_WMI, is a deliberate choice to provide context for the WMI and SMM
backends, which would otherwise appear to float without context within
the menu.
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Some race conditions were raised due to dell-smbios and its backends
not being ready by the time that a consumer would call one of the
exported methods.

To avoid this problem, guarantee that all initialization has been
done by linking them all together and running init for them all.

As part of this change the Kconfig needs to be adjusted so that
CONFIG_DELL_SMBIOS_SMM and CONFIG_DELL_SMBIOS_WMI are boolean
rather than modules.

CONFIG_DELL_SMBIOS is a visually selectable option again and both
CONFIG_DELL_SMBIOS_WMI and CONFIG_DELL_SMBIOS_SMM are optional.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
[dvhart: Update prompt and help text for DELL_SMBIOS_* backends]
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Topstar U931 laptops provide a LED synced with the WLAN adapter
hard-blocking state. Unfortunately, some models seem to be defective,
making impossible to hard-block the adapter with the WLAN switch and
thus the LED is useless.

An ACPI method is available to programmatically control this switch and
it indirectly allows to control the LED.

This commit registers the LED within the corresponding subsystem, making
possible for instance to use an rfkill-based trigger to synchronize the
LED with the device state.

This workaround is enabled automatically for Topstar U931/RVP7 laptops
based on a DMI check.
Signed-off-by: NGuillaume Douézan-Grard <gdouezangrard@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

1) Charge start threshold
/sys/class/power_supply/BATN/charge_start_threshold

Valid values are [0, 99]. A value of 0 turns off the
start threshold wear control.

2) Charge stop threshold
/sys/class/power_supply/BATN/charge_stop_threshold

Valid values are [1, 100]. A value of 100 turns off
the stop threshold wear control. This must be
configured first.
Signed-off-by: NOgnjen Galic <smclt30p@gmail.com>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

It makes mlx-platform available for 32 bit architecture.
Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

In preparation for making the hotplug driver build for different
architectures, move mlxcpld-hotplug.c to platform/mellanox and the
header to include/linux/platform_data as mlxreg.h to reflect the new
interface changes to come.

Replace references to CPLD with REG throughout the files, consistent
with the new name.
Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
[dvhart: update copyright, rewrite commit message]
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

This adds list of supported features by this driver to the Kconfig.
Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Allow the driver to be a module since builtin_pci_driver funtionality is no
longer needed.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Drivers should not 'select' a subsystem. Instead they should depend
on it. If the subsystem is disabled, the user probably did that for
a purpose and one driver shouldn't be changing that.

This also makes all platform/x86/ drivers consistent w.r.t depending on
INPUT instead of selecting it.
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
Cc: platform-driver-x86@vger.kernel.org
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Add a driver for the GPD pocket device's custom fan controller, which
gets controlled through 2 GPIOs listed in a FAN02501 ACPI device.

Cc: James <kernel@madingley.org>
Suggested-by: NJames <kernel@madingley.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

This provides a new input driver for supporting the power button on
Dollar Cove TI PMIC, found on Cherrytrail-based devices.
The patch is based on the original work by Intel, found at:
  https://github.com/01org/ProductionKernelQuilts

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

New Acer laptops in 2018 will have a separate ACPI device for
notifications from the airplane mode hotkey. The device name in
the DSDT is SMKB and its ACPI _HID is 10251229.

For these models, when the airplane mode hotkey (Fn+F3) pressed,
a query 0x02 is started in the Embedded Controller, and all this
query does is a notify SMKB with the value 0x80.

        Scope (_SB.PCI0.LPCB.EC0)
        {
                (...)
                Method (_Q02, 0, NotSerialized)  // _Qxx: EC Query
                {
                    HKEV (0x2, One)
		    Notify (SMKB, 0x80)	// Status Change
                }
        }

Based on code from asus-wireless
Signed-off-by: NChris Chiu <chiu@endlessm.com>
Reviewed-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The updates this merge window added several bogus default enablement for
new features.  We don't do that.  If people want new behavior, they ask
for it.

One 'default n' was also removed as pointless.  That's great, but there
were eight other ones in the same file that were left alone.

Fix it up.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The dell-smbios stack only currently uses an SMI interface which grants
direct access to physical memory to the firmware SMM methods via a pointer.

This dispatcher driver adds a WMI-ACPI interface that is detected by WMI
probe and preferred over the SMI interface in dell-smbios.

Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
for a buffer of data storage when SMM calls are performed.

This is a safer approach to use in kernel drivers as the SMM will
only have access to that OperationRegion.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

This splits up the dell-smbios driver into two drivers:
* dell-smbios
* dell-smbios-smm

dell-smbios can operate with multiple different dispatcher drivers to
perform SMBIOS operations.

Also modify the interface that dell-laptop and dell-wmi use align to this
model more closely.  Rather than a single global buffer being allocated
for all drivers, each driver will allocate and be responsible for it's own
buffer. The pointer will be passed to the calling function and each
dispatcher driver will then internally copy it to the proper location to
perform it's call.

Add defines for calls used by these methods in the dell-smbios.h header
for tracking purposes.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

All communication on individual GUIDs should occur in separate drivers.
Allowing a driver to communicate with the bus to another GUID is just
a hack that discourages drivers to adopt the bus model.

The information found from the WMI descriptor driver is now exported
for use by other drivers.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

The fusb302 driver as merged in staging uses "typec_fusb302" as i2c-id
rather then just "fusb302" and needs us to set a number of device-
properties, adjust the intel_cht_int33fe driver accordingly.

One of the properties set is max-snk-mv which makes the fusb302 driver
negotiate up to 12V charging voltage, which is a bad idea on boards
which are not setup to handle this, so this commit also adds 2 extra
sanity checks to make sure that the expected Whiskey Cove PMIC +
TI bq24292i charger combo, which can handle 12V, is present.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

'default n' is a default behaviour of Kconfig options. So, remove
explicit line from Kconfig.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

This patch fixes some spelling typos found in Kconfig files.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This driver serves the purpose of responding to WMI based notifications
from the DELL_EVENT_GUID (9DBB5994-A997-11DA-B012-B622A1EF5492).
Other GUIDs will be handled by separate drivers.

Update the language used by this driver to avoid future confusion.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Current implementations of Intel Thunderbolt controllers will go
into a low power mode when not in use.

Many machines containing these controllers also have a GPIO wired up
that can force the controller awake.  This is offered via a ACPI-WMI
interface intended to be manipulated by a userspace utility.

This mechanism is provided by Intel to OEMs to include in BIOS.
It uses an industry wide GUID that is populated in a separate _WDG
entry with no binary MOF.

This interface allows software such as fwupd to wake up thunderbolt
controllers to query the firmware version or flash new firmware.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NYehezkel Bernat <yehezkel.bernat@intel.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
[andy fixed merge conflicts and bump kernel version for ABI]
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The new driver fails to build without INPUT_POLLDEV

drivers/platform/x86/peaq-wmi.o: In function `peaq_wmi_exit':
peaq-wmi.c:(.exit.text+0x1c): undefined reference to `input_unregister_polled_device'
drivers/platform/x86/peaq-wmi.o: In function `peaq_wmi_init':
peaq-wmi.c:(.init.text+0x23): undefined reference to `input_allocate_polled_device'
peaq-wmi.c:(.init.text+0x18e): undefined reference to `input_register_polled_device'

For some reason, all other drivers that need this use 'select'
here rather than 'depends on', so I'm doing the same.

Fixes: 13bb0fd5 ("platform/x86: peaq-wmi: Add new peaq-wmi driver")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Using a dedicated Kconfig option for enabling debugging means the user
may be forced to recompile their kernel in order to gather debugging
information, which is inconvenient.  Replace custom debugging
infrastructure with standard logging functions, taking advantage of
dynamic debug.  Replace a pr_info() call inside an ACPI callback with an
acpi_handle_info() call.

The following mapping was used:

  - FUJLAPTOP_DBG_ERROR -> acpi_handle_err()
  - FUJLAPTOP_DBG_WARN  -> acpi_handle_info() / dev_info()
  - FUJLAPTOP_DBG_INFO  -> acpi_handle_debug()
  - FUJLAPTOP_DBG_TRACE -> acpi_handle_debug() / dev_dbg()

This means that some events which used to only be logged when the user
explicitly requested it will now be logged by default:

  - ACPI method evaluation errors,
  - unknown ACPI notification codes,
  - unknown hotkey scancodes.

The first type of events should happen rarely, if ever at all.  The rest
is interesting from driver development perspective as their presence in
the logs will mean the driver is unaware of certain events, handling of
which should be implemented.
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>

Some peripherals on Bay Trail and Cherry Trail platforms signal a
Power Management Event (PME) to the Power Management Controller (PMC)
to wakeup the system. When this happens software needs to explicitly
clear the PME bus 0 status bit in the GPE0a_STS register to avoid an
IRQ storm on IRQ 9.

This is modelled in ACPI through the INT0002 ACPI device, which is
called a "Virtual GPIO controller" in ACPI because it defines the
event handler to call when the PME triggers through _AEI and _L02
methods as would be done for a real GPIO interrupt in ACPI.

This commit adds a driver which registers the Virtual GPIOs expected
by the DSDT on these devices, letting gpiolib-acpi claim the
virtual GPIO and install a GPIO-interrupt handler which call the _L02
handler as it would for a real GPIO controller.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>