On some X86 devices we do not register an input-device, because the
power-button is also handled by the soc_button_array (GPIO) input driver,
and we want to avoid reporting power-button presses to userspace twice.

Sofar when we did this we also did not register our interrupt handlers,
since those were only necessary to report input events.

But on at least 2 device models the Medion Akoya E1239T and the GPD win,
the GPIO pin used by the soc_button_array driver for the power-button
cannot wakeup the system from suspend. Why this does not work is not clear,
I've tried comparing the value of all relevant registers on the Cherry
Trail SoC, with those from models where this does work. I've checked:
PMC registers: FUNC_DIS, FUNC_DIS2, SOIX_WAKE_EN, D3_STS_0, D3_STS_1,
D3_STDBY_STS_0, D3_STDBY_STS_1; PMC ACPI I/O regs: PM1_STS_EN, GPE0a_EN
and they all have identical contents in the working and non working cases.
I suspect that the firmware either sets some unknown register to a value
causing this, or that it turns off a power-plane which is necessary for
GPIO wakeups to work during suspend.

What does work on the Medion Akoya E1239T is letting the AXP288 wakeup
the system on a power-button press (the GPD win has a different PMIC).

Move the registering of the power-button press/release interrupt-handler
from axp20x_pek_probe_input_device() to axp20x_pek_probe() so that the
PMIC will wakeup the system on a power-button press, even if we do not
register an input device.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NChen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20200426155757.297087-1-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The 'pengutronix' address is defunct for years. Use the proper contact
address.
Signed-off-by: NWolfram Sang <wsa@kernel.org>
Link: https://lore.kernel.org/r/20200502142639.18925-1-wsa@kernel.orgSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Fix to return a negative error code from the input_register_device()
error handling case instead of 0, as done elsewhere in this function.
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20200428134948.78343-1-weiyongjun1@huawei.com
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Fix a use-after-free noticed by running with KASAN enabled. If
rmi_irq_fn() is run twice in a row, then rmi_f11_attention() (among
others) will end up reading from drvdata->attn_data.data, which was
freed and left dangling in rmi_irq_fn().

Commit 55edde9f ("Input: synaptics-rmi4 - prevent UAF reported by
KASAN") correctly identified and analyzed this bug. However the attempted
fix only NULLed out a local variable, missing the fact that
drvdata->attn_data is a struct, not a pointer.

NULL out the correct pointer in the driver data to prevent the attention
functions from copying from it.

Fixes: 55edde9f ("Input: synaptics-rmi4 - prevent UAF reported by KASAN")
Fixes: b908d3cd ("Input: synaptics-rmi4 - allow to add attention data")
Signed-off-by: NEvan Green <evgreen@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200427145537.1.Ic8f898e0147beeee2c005ee7b20f1aebdef1e7eb@changeidSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

On the Lenovo ThinkPad Twist S230u (3347-4HU) with BIOS version
"GDETC1WW (1.81 ) 06/27/2019", the keyboard, Synaptics TouchPad, and
TrackPoint either do not function or stop functioning a few minutes
after boot.  This problem has been noted before, perhaps only occurring
with BIOS 1.57 and later.[1][2][3][4][5]

Odds of a BIOS fix appear to be low: 1.57 was released over 6 years ago
and although the [BIOS changelog] notes "Fixed an issue of UEFI
touchpad/trackpoint/keyboard/touchscreen" in 1.58, it appears to be
insufficient.

Setting i8042.reset=1 or adding 33474HU to the reset list avoids the
issue on my system from either warm or cold boot.

[1]: https://bugs.launchpad.net/bugs/1210748
[2]: https://bbs.archlinux.org/viewtopic.php?pid=1360425
[3]: https://forums.linuxmint.com/viewtopic.php?f=46&t=41200
[4]: https://forums.linuxmint.com/viewtopic.php?f=49&t=157115
[5]: https://forums.lenovo.com/topic/findpost/27/1337119
[BIOS changelog]: https://download.lenovo.com/pccbbs/mobiles/gduj33uc.txtSigned-off-by: NKevin Locke <kevin@kevinlocke.name>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/94f384b0f75f90f71425d7dce7ac82c59ddb87a8.1587702636.git.kevin@kevinlocke.nameSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This reverts commit 18931506. From Kevin
Locke:

"... nomux only appeared to fix the issue because the controller
continued working after warm reboots. After more thorough testing from
both warm and cold start, I now believe the entry should be added to
i8042_dmi_reset_table rather than i8042_dmi_nomux_table as i8042.reset=1
alone is sufficient to avoid the issue from both states while
i8042.nomux is not."

According to the file name and Kconfig, a 'k' is missing in this driver
name. It should be "dlink-dir685-touchkeys".

Fixes: 131b3de7 ("Input: add D-Link DIR-685 touchkeys driver")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200412213937.5287-1-christophe.jaillet@wanadoo.frSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Sending [ 0x05, 0x20, 0x00, 0x0f, 0x06 ] packet for Xbox One S controllers
fixes an issue where controller is stuck in Bluetooth mode and not sending
any inputs.
Signed-off-by: NŁukasz Patron <priv.luk@gmail.com>
Reviewed-by: NCameron Gutman <aicommander@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200422075206.18229-1-priv.luk@gmail.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

input_flush_device() should only be called once the struct file is being
released and no open descriptors remain, but evdev_flush() was calling
it whenever a file descriptor was closed.

This caused uploaded force-feedback effects to be erased when a process
did a dup()/close() on the event FD, called system(), etc.

Call input_flush_device() from evdev_release() instead.
Reported-by: NMathieu Maret <mathieu.maret@gmail.com>
Signed-off-by: NBrendan Shanks <bshanks@codeweavers.com>
Link: https://lore.kernel.org/r/20200421231003.7935-1-bshanks@codeweavers.com
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

On the Lenovo ThinkPad Twist S230u (3347-4HU) with BIOS version
"GDETC1WW (1.81 ) 06/27/2019", whether booted in UEFI or Legacy/CSM mode
the keyboard, Synaptics TouchPad, and TrackPoint either do not function
or stop functioning a few minutes after boot.  This problem has been
noted before, perhaps only occurring on BIOS 1.57 and
later.[1][2][3][4][5]

This model does not have an external PS/2 port, so mux does not appear
to be useful.

Odds of a BIOS fix appear to be low: 1.57 was released over 6 years ago
and although the [BIOS changelog] notes "Fixed an issue of UEFI
touchpad/trackpoint/keyboard/touchscreen" in 1.58, it appears to be
insufficient.

Adding 33474HU to the nomux list avoids the issue on my system.

[1]: https://bugs.launchpad.net/bugs/1210748
[2]: https://bbs.archlinux.org/viewtopic.php?pid=1360425
[3]: https://forums.linuxmint.com/viewtopic.php?f=46&t=41200
[4]: https://forums.linuxmint.com/viewtopic.php?f=49&t=157115
[5]: https://forums.lenovo.com/topic/findpost/27/1337119
[BIOS changelog]: https://download.lenovo.com/pccbbs/mobiles/gduj33uc.txtSigned-off-by: NKevin Locke <kevin@kevinlocke.name>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/feb8a8339a67025dab3850e6377eb6f3a0e782ba.1587400635.git.kevin@kevinlocke.nameSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Based on available information this uses the singletouch irtouch
protocol. This is tested and confirmed to be fully functional on
the BonXeon TP hardware I have.
Signed-off-by: NJames Hilliard <james.hilliard1@gmail.com>
Link: https://lore.kernel.org/r/20200413184217.55700-1-james.hilliard1@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This patch makes use of cros_ec_cmd_xfer_status() instead of
cros_ec_cmd_xfer(). In this case there is no advantage of doing this
apart from that we want to make cros_ec_cmd_xfer() a private function
for the EC protocol and let people only use the
cros_ec_cmd_xfer_status() to return Linux standard error codes.
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200414210434.1534982-1-enric.balletbo@collabora.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

MMS345L is another first generation touch screen from Melfas,
which uses the same registers as MMS152.

However, using I2C_M_NOSTART for it causes errors when reading:

	i2c i2c-0: sendbytes: NAK bailout.
	mms114 0-0048: __mms114_read_reg: i2c transfer failed (-5)

The driver works fine as soon as I2C_M_NOSTART is removed.
Reviewed-by: NAndi Shyti <andi@etezian.org>
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200405170904.61512-1-stephan@gerhold.net
[dtor: removed separate mms345l handling, made everyone use standard
transfer mode, propagated the 10bit addressing flag to the read part of the
transfer as well.]
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Elan uses the least significant bit of byte 33 to signal the type of
contact (finger versus palm). The default value is 1 for all firmwares,
which is reported as MT_TOOL_FINGER. If firmware supports palm detection,
the bit will change to 0 and the driver will report such contact as
MT_TOOL_PALM.
Signed-off-by: NJohnny Chuang <johnny.chuang@emc.com.tw>
Reviewed-by: NPeter Hutterer <peter.hutterer@who-t.net>
Link: https://lore.kernel.org/r/1585551756-29066-1-git-send-email-johnny.chuang.emc@gmail.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Prepare input updates for 5.7 merge window.

Replace the
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
with
/* SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note */

to help coreboot community consume this file without relaxing their
licensing checks.
Signed-off-by: NRajat Jain <rajatja@google.com>
Link: https://lore.kernel.org/r/20200329172513.133548-1-rajatja@google.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The Acer Aspire 5738z has a button to disable (and re-enable) the
touchpad next to the touchpad.

When this button is pressed a LED underneath indicates that the touchpad
is disabled (and an event is send to userspace and GNOME shows its
touchpad enabled / disable OSD thingie).

So far so good, but after re-enabling the touchpad it no longer works.

The laptop does not have an external ps2 port, so mux mode is not needed
and disabling mux mode fixes the touchpad no longer working after toggling
it off and back on again, so lets add this laptop model to the nomux list.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200331123947.318908-1-hdegoede@redhat.com
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

acpi_evaluate_object() and acpi_execute_simple_method() are not part of
the group of ACPI related functions which get stubbed by
include/linux/acpi.h when ACPI support is disabled, so the
IRQ_PIN_ACCESS_ACPI_METHOD handling code must be stubbed out.

For consistency use the same #if condition as which is used to replace
goodix_add_acpi_gpio_mappings with a stub.

Fixes: c5fca485 ("Input: goodix - add support for controlling the IRQ pin through ACPI methods")
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200401014529.GL75430@dtor-ws
[dtor: stubbed out the ACPI method accessors]
Reviewed-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

We need to refresh timestamp when emitting key autorepeat events, otherwise
they will carry timestamp of the original key press event.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206929
Fixes: 3b51c44b ("Input: allow drivers specify timestamp for input events")
Cc: stable@vger.kernel.org
Reported-by: Nteika kazura <teika@gmx.com>
Tested-by: Nteika kazura <teika@gmx.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

We should try to keep keycodes sequential unless there is a reason to leave
a gap in numbering, so let's move it from 0x280 to 0x27a while we still
can.

Fixes: 3b059da9 ("Input: allocate keycode for Selective Screenshot key")
Acked-by: NRajat Jain <rajatja@google.com>
Link: https://lore.kernel.org/r/20200326182711.GA259753@dtor-wsSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Convert the EDT-FT5x06 to DT schema using json-schema.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@st.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200207084657.31195-1-benjamin.gaignard@st.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The commit 19ba1eb1 ("Input: psmouse - add a custom serio protocol
to send extra information") introduced usage of the BIT() macro
for SERIO_* flags; this macro is not provided in UAPI headers.
Replace if with similarly defined _BITUL() macro defined
in <linux/const.h>.

Fixes: 19ba1eb1 ("Input: psmouse - add a custom serio protocol to send extra information")
Signed-off-by: NEugene Syromiatnikov <esyr@redhat.com>
Cc: <stable@vger.kernel.org> # v5.0+
Link: https://lore.kernel.org/r/20200324041341.GA32335@asgard.redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The previous patch "c5ccf2ad (Input: synaptics-rmi4 - switch to
reduced reporting mode)" enabled reduced reporting mode unintentionally
on some devices, if the firmware was configured with default Delta X/Y
threshold values. The result unintentionally degrade the performance of
some touchpads.

This patch checks to see that the driver is modifying the delta X/Y
thresholds before modifying the reporting mode.
Signed-off-by: NAndrew Duggan <aduggan@synaptics.com>
Fixes: c5ccf2ad ("Input: synaptics-rmi4 - switch to reduced reporting mode")
Link: https://lore.kernel.org/r/20200312005549.29922-1-aduggan@synaptics.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This laptop (and perhaps other variants of the same model) reports an
SMBus-capable Synaptics touchpad. Everything (including suspend and
resume) works fine when RMI is enabled via the kernel command line, so
let's add it to the whitelist.
Signed-off-by: NYussuf Khalil <dev@pp3345.net>
Link: https://lore.kernel.org/r/20200307213508.267187-1-dev@pp3345.net
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The 'axis + 1' calculation is implicit and potentially error prone.
Moreover, few lines before the axis is set explicitly for both X and Y.

Do the same when retrieving different properties for X and Y.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200303180917.12563-1-andriy.shevchenko@linux.intel.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Add support for it by adding compatible and supported chip data
(default settings used).
The chip data on GT9147 is similar to GT912, like
- config data register has 0x8047 address
- config data register max len is 240
- config data checksum has 8-bit
Signed-off-by: NYannick Fertre <yannick.fertre@st.com>
Reviewed-by: NBastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/1583144308-3781-3-git-send-email-yannick.fertre@st.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Add support for it by adding compatible.
The chip data on GT9147 is similar to GT912, like
- config data register has 0x8047 address
- config data register max len is 240
- config data checksum has 8-bit
Signed-off-by: NYannick Fertre <yannick.fertre@st.com>
Acked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/1583144308-3781-2-git-send-email-yannick.fertre@st.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Goodix GT917S is a touchscreen chip from Goodix that is in the GT1x
family.

Add its support by assigning the gt1x config to it.
Signed-off-by: NIcenowy Zheng <icenowy@aosc.io>
Reviewed-by: NBastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20200228010146.12215-4-icenowy@aosc.ioSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

For Goodix GT917S chip, the chip ID string is "917S", which contains not
only numbers now.

Use string-based chip ID in the driver to support this chip and further
chips with alphanumber ID.
Signed-off-by: NIcenowy Zheng <icenowy@aosc.io>
Reviewed-by: NBastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20200228010146.12215-3-icenowy@aosc.ioSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Goodix GT917S is a new touchscreen chip from Goodix.

Add its compatible string to the device tree binding.
Signed-off-by: NIcenowy Zheng <icenowy@aosc.io>
Acked-by: NRob Herring <robh@kernel.org>
Reviewed-by: NBastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20200228010146.12215-2-icenowy@aosc.ioSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Some devices with a goodix touchscreen have more then 1 capacitive
touch-key. This commit replaces the current support for a single
touch-key, which ignored the reported key-code. With support for
up to 7 touch-keys, based upon checking the key-code which is
post-fixed to any reported touch-data.

KEY_LEFTMETA is assigned to the first touch-key (it will still be
the default keycode for devices with a single touch-key).
KEY_F1, KEY_F2... are assigned as default keycode for the other
touch-keys.

This commit also add supports for keycode remapping, so that
systemd-udev's hwdb can be used to remap the codes to send
keycodes to match the icons on the buttons for devices with more
then 1 touch-key.
Signed-off-by: NDmitry Mastykin <dmastykin@astralinux.ru>
Reviewed-by: NBastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20200316075302.3759-1-dmastykin@astralinux.ruSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The goodix panel sends spurious interrupts after a 'finger up' event,
which always cause a timeout.
We were exiting the interrupt handler by reporting touch_num == 0, but
this was still processed as valid and caused the code to use the
uninitialised point_data, creating spurious key release events.

Report an error from the interrupt handler so as to avoid processing
invalid point_data further.
Signed-off-by: NDmitry Mastykin <dmastykin@astralinux.ru>
Reviewed-by: NBastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20200316075302.3759-2-dmastykin@astralinux.ruSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

On some ACPI/x86 devices (where we use one of the ACPI IRQ pin access
methods) the firmware is buggy, it does not properly reset the controller
at boot, and we cannot communicate with it.

Normally on ACPI/x86 devices we do not want to reset the controller at
probe time since in some cases this causes the controller to loose its
configuration and this is loaded into it by the system's firmware.
So on these systems we leave the reset_controller_at_probe flag unset,
even though we have a access to both the IRQ and reset pins and thus
could reset it.

In the case of the buggy firmware we have to reset the controller to
actually be able to talk to it.

This commit adds a special case for this, if the goodix_i2c_test() fails,
and we have not reset the controller yet; and we do have a way to reset
the controller then retry the i2c-test after resetting the controller.

This fixes the driver failing at probe on ACPI/x86 systems with this
firmware bug.
Reported-and-tested-by: NDmitry Mastykin <dmastykin@astralinux.ru>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200311191013.10826-2-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Some devices, e.g the Trekstor Primetab S11B, lose there config over
a suspend/resume cycle (likely the controller loses power during suspend).

This commit reads back the config version on resume and if matches the
expected config version it resets the controller and resends the config
we read back and saved at probe time.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317
BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200307121505.3707-11-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Make goodix_send_cfg() take a raw buffer as argument instead of a
struct firmware *cfg, so that it can also be used to restore the config
on resume if necessary.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317
BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200307121505.3707-10-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Our goodix_check_cfg_* helpers do things like:

	int i, raw_cfg_len = cfg->size - 2;
	...
	if (check_sum != cfg->data[raw_cfg_len]) {

When cfg->size < 2, this will end up indexing the cfg->data array with
a negative value, which will not end well.

To fix this this commit adds a new GOODIX_CONFIG_MIN_LENGTH define and
adds a minimum size check for firmware-config files using this new define.

For consistency this commit also adds a new GOODIX_CONFIG_GT9X_LENGTH for
the length used for recent gt9xx and gt1xxx chips, instead of using
GOODIX_CONFIG_MAX_LENGTH for this, so that if other length defines get
added in the future it will be clear that the MIN and MAX defines should
contain the min and max values of all the other defines.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20200307121505.3707-9-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Save a copy of the config in goodix_read_config(), this is a preparation
patch for restoring the config if it was lost after a supend/resume cycle.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317
BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200307121505.3707-8-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Move the  defines to above the struct goodix_ts_data declaration, so
that the MAX defines can be used inside the struct goodix_ts_data
declaration. No functional changes, just moving a block of code.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317
BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200307121505.3707-7-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Some Apollo Lake (x86, UEFI + ACPI) devices only list the reset GPIO
in their _CRS table and the bit-banging of the IRQ line necessary to
wake-up the controller from suspend can be done by calling 2 Goodix
custom / specific ACPI methods.

This commit adds support for controlling the IRQ line in this matter,
allowing us to properly suspend the touchscreen controller on such
devices.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317
BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200307121505.3707-6-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

On most Bay Trail (x86, UEFI + ACPI) devices the ACPI tables do not have
a _DSD with a "daffd814-6eba-4d8c-8a91-bc9bbf4aa301" UUID, adding
"irq-gpios" and "reset-gpios" mappings, so we cannot get the GPIOS by name
without first manually adding mappings ourselves.

These devices contain 2 GpioIo resource in their _CRS table, on all 4 such
devices which I have access to, the order of the 2 GPIOs is reset, int.

Note that the GPIO to which the touchscreen controller irq pin is connected
is configured in direct-irq mode on these Bay Trail devices, the
pinctrl-baytrail.c driver still allows controlling the pin as a GPIO in
this case, but this is not necessarily the case on other X86 ACPI
platforms, nor do we have a guarantee that the GPIO order is the same
elsewhere, so we limit the use of a _CRS table with 2 GpioIo resources
to Bay Trail devices only.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1786317
BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199207Reviewed-by: NBastien Nocera <hadess@hadess.net>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200307121505.3707-5-hdegoede@redhat.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>