Input: soc_button_array - add mapping for airplane mode button

This add a mapping for the airplane mode button on the TUXEDO Pulse Gen3.

While it is physically a key it behaves more like a switch, sending a key
down on first press and a key up on 2nd press. Therefor the switch event
is used here. Besides this behaviour it uses the HID usage-id 0xc6
(Wireless Radio Button) and not 0xc8 (Wireless Radio Slider Switch), but
since neither 0xc6 nor 0xc8 are currently implemented at all in
soc_button_array this not to standard behaviour is not put behind a quirk
for the moment.

Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Link: https://lore.kernel.org/r/20231215171718.80229-1-wse@tuxedocomputers.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230920125829.1478827-25-u.kleine-koenig@pengutronix.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - add invalid acpi_index DMI quirk handling

Some devices have a wrong entry in their button array which points to
a GPIO which is required in another driver, so soc_button_array must
not claim it.

A specific example of this is the Lenovo Yoga Book X90F / X90L,
where the PNP0C40 home button entry points to a GPIO which is not
a home button and which is required by the lenovo-yogabook driver.

Add a DMI quirk table which can specify an ACPI GPIO resource index which
should be skipped; and add an entry for the Lenovo Yoga Book X90F / X90L
to this new DMI quirk table.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20230414072116.4497-1-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - add Acer Switch V 10 to dmi_use_low_level_irq[]

Like on the Acer Switch 10 SW5-012, the Acer Switch V 10 SW5-017's _LID
method messes with home- and power-button GPIO IRQ settings, causing an
IRQ storm.

Add a quirk entry for the Acer Switch V 10 to the dmi_use_low_level_irq[]
DMI quirk list, to use low-level IRQs on this model, fixing the IRQ storm.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20221106215320.67109-2-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - add use_low_level_irq module parameter

It seems that the Windows drivers for the ACPI0011 soc_button_array
device use low level triggered IRQs rather then using edge triggering.

Some ACPI tables depend on this, directly poking the GPIO controller's
registers to clear the trigger type when closing a laptop's/2-in-1's lid
and re-instating the trigger when opening the lid again.

Linux sets the edge/level on which to trigger to both low+high since
it is using edge type IRQs, the ACPI tables then ends up also setting
the bit for level IRQs and since both low and high level have been
selected by Linux we get an IRQ storm leading to soft lockups.

As a workaround for this the soc_button_array already contains
a DMI quirk table with device models known to have this issue.

Add a module parameter for this so that users can easily test if their
device is affected too and so that they can use the module parameter
as a workaround.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20221106215320.67109-1-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - also add Lenovo Yoga Tablet2 1051F to dmi_use_low_level_irq

Commit 223f61b8c5ad ("Input: soc_button_array - add Lenovo Yoga Tablet2
1051L to the dmi_use_low_level_irq list") added the 1051L to this list
already, but the same problem applies to the 1051F. As there are no
further 1051 variants (just the F/L), we can just DMI match 1051.

Tested on a Lenovo Yoga Tablet2 1051F: Without this patch the
home-button stops working after a wakeup from suspend.

Signed-off-by: Marius Hoch <mail@mariushoch.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220603120246.3065-1-mail@mariushoch.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - add support for Microsoft Surface 3 (MSHW0028) buttons

The drivers/platform/surface/surface3_button.c code is alsmost a 1:1 copy
of the soc_button_array code.

The only big difference is that it binds to an i2c_client rather then to
a platform_device. The cause of this is the ACPI resources for the MSHW0028
device containing a bogus I2cSerialBusV2 resource which causes the kernel
to instantiate an i2c_client for it instead of a platform_device.

Add "MSHW0028" to the ignore_serial_bus_ids[] list in drivers/apci/scan.c,
so that a platform_device will be instantiated and add support for
the MSHW0028 HID to soc_button_array.

This fully replaces surface3_button, which will be removed in a separate
commit (since it binds to the now no longer created i2c_client it no
longer does anyyhing after this commit).

Note the MSHW0028 id is used by Microsoft to describe the tablet buttons on
both the Surface 3 and the Surface 3 Pro and the actual API/implementation
for the Surface 3 Pro is quite different. The changes in this commit should
not impact the separate surfacepro3_button driver:

1. Because of the bogus I2cSerialBusV2 resource problem that driver binds
to the acpi_device itself, so instantiating a platform_device instead of
an i2c_client does not matter.

2. The soc_button_array driver will not bind to the MSHW0028 device on
the Surface 3 Pro, because it has no GPIO resources.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20220224110241.9613-2-hdegoede@redhat.com

Input: soc_button_array - add Lenovo Yoga Tablet2 1051L to the dmi_use_low_level_irq list

Add the Lenovo Yoga Tablet2 1051L to the list of devices where the
ACPI AML code is poking the GPIO config register directly changing
the IRQ type to a low_level_irq, which we need to work around.

This fixes the home button on the Lenovo Yoga Tablet2 1051L not
working.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20201206161245.24798-1-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - add missing include

This fixes the following build errors:

CC [M] drivers/input/misc/soc_button_array.o
drivers/input/misc/soc_button_array.c:156:4: error: implicit declaration of function 'irq_set_irq_type' [-Werror,-Wimplicit-function-declaration]
irq_set_irq_type(irq, IRQ_TYPE_LEVEL_LOW);
^
drivers/input/misc/soc_button_array.c:156:26: error: use of undeclared identifier 'IRQ_TYPE_LEVEL_LOW'
irq_set_irq_type(irq, IRQ_TYPE_LEVEL_LOW);
^
2 errors generated.

Fixes: 78a5b53e9fb4 ("Input: soc_button_array - work around DSDTs which modify the irqflags")
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20201123061508.GA1009828@dtor-ws
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - work around DSDTs which modify the irqflags

Some 2-in-1s which use the soc_button_array driver have this ugly issue in
their DSDT where the _LID method modifies the irq-type settings of the
GPIOs used for the power and home buttons. The intend of this AML code is
to disable these buttons when the lid is closed.

The AML does this by directly poking the GPIO controllers registers. This
is problematic because when re-enabling the irq, which happens whenever
_LID gets called with the lid open (e.g. on boot and on resume), it sets
the irq-type to IRQ_TYPE_LEVEL_LOW. Where as the gpio-keys driver programs
the type to, and expects it to be, IRQ_TYPE_EDGE_BOTH.

This commit adds a workaround for this which (on affected devices) does
not set gpio_keys_button.gpio on these 2-in-1s, instead it gets the irq for
the GPIO, configures it as IRQ_TYPE_LEVEL_LOW (to match how the _LID AML
code configures it) and passes the irq in gpio_keys_button.irq.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200906122016.4628-2-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - add support for INT33D3 tablet-mode switch devices

According to the Microsoft documentation for Windows 8 convertible
devices, these devices should implement a PNP0C60 "laptop/slate mode state
indicator" ACPI device.

This device can work in 2 ways, if there is a GPIO which directly
indicates the device is in tablet-mode or not then the direct-gpio mode
should be used. If there is no such GPIO, but instead the events are
coming from e.g. the embedded-controller, then there should still be
a PNP0C60 ACPI device and event-injection should be used to send the
events. The drivers/platform/x86/intel-vbtn.c code is an example from
a standardized manner of doing the latter.

On various 2-in-1s with either a detachable keyboard, or with 360°
hinges, the direct GPIO mode is indicated by an ACPI device with a
HID of INT33D3, which contains a single GpioInt in its ACPI resource
table, which directly indicates if the device is in tablet-mode or not.

This commit adds support for this to the soc_button_array code, as
well as for the alternative ID9001 HID which some devices use
instead of the INT33D3 HID.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200826150601.12137-3-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - add active_low setting to soc_button_info

This is a preparation patch for adding support for Intel INT33D3
ACPI devices. These INT33D3 devices follow yet another Intel defined
(but not documented) ACPI GPIO button standard.

Unlike the ACPI GPIO button devices supported so far, the GPIO used in
the INT33D3 devices is active-high, rather then active-low.

This commit makes setting the gpio_keys_button.active_low flag
configurable through the soc_button_info struct and enables it for all
currently supported devices.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200826150601.12137-2-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - partial revert of support for newer surface devices

Commit c394159310d0 ("Input: soc_button_array - add support for newer
surface devices") not only added support for the MSHW0040 ACPI HID,
but for some reason it also makes changes to the error handling of the
soc_button_lookup_gpio() call in soc_button_device_create(). Note ideally
this seamingly unrelated change would have been made in a separate commit,
with a message explaining the what and why of this change.

I guess this change may have been added to deal with -EPROBE_DEFER errors,
but in case of the existing support for PNP0C40 devices, treating
-EPROBE_DEFER as any other error is deliberate, see the comment this
commit adds for why.

The actual returning of -EPROBE_DEFER to the caller of soc_button_probe()
introduced by the new error checking causes a serious regression:

On devices with so called virtual GPIOs soc_button_lookup_gpio() will
always return -EPROBE_DEFER for these fake GPIOs, when this happens
during the second call of soc_button_device_create() we already have
successfully registered our first child. This causes the kernel to think
we are making progress with probing things even though we unregister the
child before again before we return the -EPROBE_DEFER. Since we are making
progress the kernel will retry deferred-probes again immediately ending
up stuck in a loop with the following showing in dmesg:

[ 124.022697] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6537
[ 124.040764] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6538
[ 124.056967] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6539
[ 124.072143] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6540
[ 124.092373] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6541
[ 124.108065] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6542
[ 124.128483] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6543
[ 124.147141] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6544
[ 124.165070] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6545
[ 124.179775] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6546
[ 124.202726] input: gpio-keys as /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6547
<continues on and on and on>

And 1 CPU core being stuck at 100% and udev hanging since it is waiting
for the modprobe of soc_button_array to return.

This patch reverts the soc_button_lookup_gpio() error handling changes,
fixing this regression.

Fixes: c394159310d0 ("Input: soc_button_array - add support for newer surface devices")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205031
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Maximilian Luz <luzmaximilian@gmail.com>
Acked-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20191005105551.353273-1-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - use platform_device_register_resndata()

The registration of gpio-keys device can be written much shorter
by using the platform_device_register_resndata() helper.

Signed-off-by: Enrico Weigelt <info@metux.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - add support for newer surface devices

Power and volume button support for 5th and 6th generation Microsoft
Surface devices via soc_button_array.

Note that these devices use the same MSHW0040 device as on the Surface
Pro 4, however the implementation is different (GPIOs vs. ACPI
notifications). Thus some checking is required to ensure we only load
this driver on the correct devices.

Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 441

Based on 1 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation version 2 of the license

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 315 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Armijn Hemel <armijn@tjaldur.nl>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190531190115.503150771@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: soc_button_array - fix mapping of the 5th GPIO in a PNP0C40 device

The Microsoft documenation for the PNP0C40 device aka the
"Windows-compatible button array" describes the 5th GpioInt listed in
the resources as: '5. Interrupt corresponding to the "Rotation Lock"
button, if supported'.

Notice this describes the 5th entry as a button while we sofar have been
mapping it to EV_SW, SW_ROTATE_LOCK. On my Point of View TAB P1006W-232
which actually comes with a rotation-lock button, the button indeed is a
button and not a slider/switch. An image search for other Windows tablets
has found 2 more models with a rotation-lock button and on both of those
it too is a push-button and not a slider/switch.

Further evidence can be found in the HUT extension HUTRR52 from Microsoft
which adds rotation lock support to the HUT, which describes 2 different
usages: "0xC9 System Display Rotation Lock Button" and
"0xCA System Display Rotation Lock Slider Switch" note that switch is seen
as a separate thing here and the non switch wording is an exact match for
the "Windows-compatible button array" spec wording.

TL;DR: our current mapping of the 5th GPIO to SW_ROTATE_LOCK is wrong
because the 5th GPIO is for a push-button not a switch.

This commit fixes this by maping the 5th GPIO to KEY_ROTATE_LOCK_TOGGLE.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - add usage-page 0x01 usage-id 0xca mapping

The ACPI0011 _DSD button descriptor on a CHT based Intel Compute Sticks
contains a mapping for usage-page 0x01 usage-id 0xca.

As described in hutrr52_system_display_rotation_lock_controls_0.pdf this
should be mapped as a "System Display Rotation Lock Slider Switch", this
commit adds support for this, silencing the following warning:

soc_button_array ACPI0011:00: Unknown button index 4 upage 01 usage ca,
ignoring

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - silence -ENOENT error on Dell XPS13 9365

The Dell XPS13 9365 has an INT33D2 ACPI node with no GPIOs, causing
the following error in dmesg:

[ 7.172275] soc_button_array: probe of INT33D2:00 failed with error -2

This commit silences this, by returning -ENODEV when there are no GPIOs.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=196679
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - fix leaking the ACPI button descriptor buffer

We are passing a buffer with ACPI_ALLOCATE_BUFFER set to
acpi_evaluate_object, so we must free it when we are done with it.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - properly map usage 0x07/0xe3 to KEY_LEFTMETA

When submitting the support for the ACPI0011 windows tablet keys device I
mapped the "windows" logo homekey to KEY_HOMEPAGE. But this is inconsistent
with how it is done on windows tablets using the old PNP0C40 ACPI device
and it does not match the HUT spec, which says that usage-page 7 usage 0xe3
is "Keyboard Left GUI".

This commit maps usage-page 7 usage 0xe3 to KEY_LEFTMETA fixing this.

Fixes: 4c3362f44980 ("Input: soc_button_array - add support for ACPI 6.0...")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - add support for ACPI 6.0 Generic Button Device

Windows 10 tablets with gpio buttons will typically use the ACPI 6.0
Generic Button Device with a HID of ACPI0011 for these buttons.

The ACPI description for these in the ACPI0011 devices _DSD object uses
something resembling HID descriptors, except that instead of indicating
a bit index into a HID input report, the index indicates the _CRS index
for the GPIO.

The use of 1 interrupt per button, some of which need to be wakeup
sources, instead of using input reports makes it impossible to use the
HID subsystem for this.

This really is just another gpio-keys input device with the platform
data described in ACPI, so this commit adds parsing for this new way
to describe gpio-keys to the soc_button_array driver.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - get rid of MAX_NBUTTONS

Count how much gpio_keys we actually need, this is a preparation patch
for adding support for the new Win10 / ACPI-6.0 "Generic Buttons Device"
support.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - Propagate error from gpiod_count()

Since gpiod_count() does not return 0 anymore, we don't need to shadow
its error code and would safely propagate to the user.

While here, replace second parameter by NULL in order to prevent side
effects on _DSD enabled firmware.

Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Input: soc_button_array - use NULL for GPIO connection ID

The gpiolib-acpi code is becoming more strict and connection-IDs
may only be used with devices which have a _DSD with matching IDs
in there. Since the soc_button_array ACPI binding is pure index
based pass in NULL as connection-ID to avoid the more strict cheks
resulting in gpiod_count and gpiod_get_index not returning any gpios.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - debounce the buttons

The soc_button_array driver was initializing (kzalloc) the
debounce_interval value to 0, leading to no debouncing at all,
while the buttons are simple mechanical switches.

This commit sets debounce_interval to 50ms to avoid spurious button
press reports both on press and release of the button. Note 50ms may
seem like a lot but soc_button_array is typically used with cheap
tablets, with not so great buttons. I tried 10ms on my tablet and it
is not enough, where as 50ms works well.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - use 'dev' instead of dereferencing it

Use local variable 'dev' instead of dereferencing it several times.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - bail out earlier if gpiod_count is zero

The PNP0C40 device of the Surface 3 doesn't have any GPIO attached to it.
Instead of trying to access the GPIO, request the count beforehand and
bail out if it is null or if an error is returned.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - use gpio_is_valid()

gpio_keys will later use gpio_is_valid(). To match the actual
behavior, we should use it here too.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - remove duplicated include

Remove duplicated include for acpi.h.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - use "Windows" key for "Home"

KEY_HOME is the key to go back to the beginning of the line, not the key to
get into an overview mode, as Windows does. GNOME can already make use of
the Windows key on multiple form factors, and other desktop environments
can use it depending on the form factor.

Using "Windows" as the emitted key also means that the keycode sent out
matches the symbol on the key itself.

So switch KEY_HOME to KEY_LEFTMETA ("Windows" key).

Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - update calls to gpiod_get*()

Add the new flags argument to calls of (devm_)gpiod_get*().

Currently both forms (with or without the flags argument) are valid thanks
to transitional macros in <linux/gpio/consumer.h>. These macros will be
removed once all consumers are updated and the flags argument will become
compulsory.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

input: misc: drop owner assignment from platform_drivers

A platform_driver does not need to set an owner, it will be populated by the
driver core.

Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Input: soc_button_array - convert to platform bus

ACPI device enumeration mechanism changed a lot since 3.16-rc1.
ACPI device objects with _HID will be enumerated to platform bus by default.
For the existing PNP drivers that probe the PNPACPI devices, the device ids
are listed explicitly in drivers/acpi/acpi_pnp.c.
But ACPI folks will continue their effort on shrinking this id list by
converting the PNP drivers to platform drivers, for the devices that don't
belong to PNP bus in nature.

Signed-off-by: Jin Yao <yao.jin@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - add missing memory allocation check

Signed-off-by: Pramod Gurav <pramod.gurav@smartplayin.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - remove duplicate inclusion of input.h

input.h was included twice.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: soc_button_array - fix a crash during rmmod

When the system has zero or one button available, trying to rmmod
soc_button_array will cause crash. Fix this by properly handling -ENODEV
in probe().

Signed-off-by: Lejun Zhu <lejun.zhu@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: add driver for SOC button array

This patch adds support for the GPIO buttons on some Intel Bay Trail
tablets originally running Windows 8. The ACPI description of these
buttons follows "Windows ACPI Design Guide for SoC Platforms".

Signed-off-by: Lejun Zhu <lejun.zhu@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>