linux-stable.git/drivers/input, branch linux-5.6.y Linux kernel stable tree Input: synaptics - add a second working PNP_ID for Lenovo T470s 2020-06-17T14:41:49+00:00 Dennis Kadioglu denk@eclipso.email 2020-05-27T06:03:13+00:00 73fc7a40af3944f3b770985e9250e8bd7108beca [ Upstream commit 642aa86eaf8f1e6fe894f20fd7f12f0db52ee03c ] The Lenovo Thinkpad T470s I own has a different touchpad with "LEN007a" instead of the already included PNP ID "LEN006c". However, my touchpad seems to work well without any problems using RMI. So this patch adds the other PNP ID. Signed-off-by: Dennis Kadioglu <denk@eclipso.email> Link: https://lore.kernel.org/r/ff770543cd53ae818363c0fe86477965@mail.eclipso.de Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 642aa86eaf8f1e6fe894f20fd7f12f0db52ee03c ]

The Lenovo Thinkpad T470s I own has a different touchpad with "LEN007a"
instead of the already included PNP ID "LEN006c". However, my touchpad
seems to work well without any problems using RMI. So this patch adds the
other PNP ID.

Signed-off-by: Dennis Kadioglu <denk@eclipso.email>
Link: https://lore.kernel.org/r/ff770543cd53ae818363c0fe86477965@mail.eclipso.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: axp20x-pek - always register interrupt handlers 2020-06-17T14:41:49+00:00 Hans de Goede hdegoede@redhat.com 2020-05-06T02:06:32+00:00 9375fc6c531be44299baf773347daf0a0067317c [ Upstream commit 9747070c11d6ae021ed7a8e96e2950ed46cd53a9 ] 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: Hans de Goede <hdegoede@redhat.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20200426155757.297087-1-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 9747070c11d6ae021ed7a8e96e2950ed46cd53a9 ]

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: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20200426155757.297087-1-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: mms114 - fix handling of mms345l 2020-06-17T14:41:49+00:00 Stephan Gerhold stephan@gerhold.net 2020-04-09T20:49:03+00:00 27c7d8d6ba3fbc15db078dbbf7e45c2aa6f21814 [ Upstream commit 3f8f770575d911c989043d8f0fb8dec96360c41c ] 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: Andi Shyti <andi@etezian.org> Signed-off-by: Stephan 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: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 3f8f770575d911c989043d8f0fb8dec96360c41c ]

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: Andi Shyti <andi@etezian.org>
Signed-off-by: Stephan 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: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: synaptics-rmi4 - fix error return code in rmi_driver_probe() 2020-06-03T06:23:13+00:00 Wei Yongjun weiyongjun1@huawei.com 2020-04-28T23:09:53+00:00 8344eab8889d05d32444822a335855a5d18401be [ Upstream commit 5caab2da63207d6d631007f592f5219459e3454d ] 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: Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20200428134948.78343-1-weiyongjun1@huawei.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 5caab2da63207d6d631007f592f5219459e3454d ]

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: Wei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20200428134948.78343-1-weiyongjun1@huawei.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: synaptics-rmi4 - really fix attn_data use-after-free 2020-06-03T06:23:13+00:00 Evan Green evgreen@chromium.org 2020-04-28T01:08:58+00:00 b94c7b0680d9477d8e186e866b810dc0f7dcab7d [ Upstream commit d5a5e5b5fa7b86c05bf073acc0ba98fa280174ec ] 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 55edde9fff1a ("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: 55edde9fff1a ("Input: synaptics-rmi4 - prevent UAF reported by KASAN") Fixes: b908d3cd812a ("Input: synaptics-rmi4 - allow to add attention data") Signed-off-by: Evan Green <evgreen@chromium.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200427145537.1.Ic8f898e0147beeee2c005ee7b20f1aebdef1e7eb@changeid Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit d5a5e5b5fa7b86c05bf073acc0ba98fa280174ec ]

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 55edde9fff1a ("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: 55edde9fff1a ("Input: synaptics-rmi4 - prevent UAF reported by KASAN")
Fixes: b908d3cd812a ("Input: synaptics-rmi4 - allow to add attention data")
Signed-off-by: Evan Green <evgreen@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200427145537.1.Ic8f898e0147beeee2c005ee7b20f1aebdef1e7eb@changeid
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: i8042 - add ThinkPad S230u to i8042 reset list 2020-06-03T06:23:13+00:00 Kevin Locke kevin@kevinlocke.name 2020-04-28T01:07:20+00:00 0eb472bc4737f9c0b6d492d2004948144cabf3bf [ Upstream commit 2712c91a54a1058d55c284152b4d93c979b67be6 ] 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.txt Signed-off-by: Kevin Locke <kevin@kevinlocke.name> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/94f384b0f75f90f71425d7dce7ac82c59ddb87a8.1587702636.git.kevin@kevinlocke.name Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 2712c91a54a1058d55c284152b4d93c979b67be6 ]

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.txt

Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/94f384b0f75f90f71425d7dce7ac82c59ddb87a8.1587702636.git.kevin@kevinlocke.name
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: dlink-dir685-touchkeys - fix a typo in driver name 2020-06-03T06:23:12+00:00 Christophe JAILLET christophe.jaillet@wanadoo.fr 2020-04-22T20:58:42+00:00 833779454d237f733435942db59e14d727baef84 [ Upstream commit 38347374ae3f1ec4df56dd688bd603a64e79a0ed ] According to the file name and Kconfig, a 'k' is missing in this driver name. It should be "dlink-dir685-touchkeys". Fixes: 131b3de7016b ("Input: add D-Link DIR-685 touchkeys driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200412213937.5287-1-christophe.jaillet@wanadoo.fr Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 38347374ae3f1ec4df56dd688bd603a64e79a0ed ]

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

Fixes: 131b3de7016b ("Input: add D-Link DIR-685 touchkeys driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200412213937.5287-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: xpad - add custom init packet for Xbox One S controllers 2020-06-03T06:23:12+00:00 Łukasz Patron priv.luk@gmail.com 2020-04-22T21:13:09+00:00 f98560b85df54ef506b28b56c41d44626b25e8cc [ Upstream commit 764f7f911bf72450c51eb74cbb262ad9933741d8 ] 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: Łukasz Patron <priv.luk@gmail.com> Reviewed-by: Cameron Gutman <aicommander@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200422075206.18229-1-priv.luk@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 764f7f911bf72450c51eb74cbb262ad9933741d8 ]

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: Łukasz Patron <priv.luk@gmail.com>
Reviewed-by: Cameron Gutman <aicommander@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200422075206.18229-1-priv.luk@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: evdev - call input_flush_device() on release(), not flush() 2020-06-03T06:23:12+00:00 Brendan Shanks bshanks@codeweavers.com 2020-04-22T20:45:12+00:00 59e5fe36e6e9b358ff037978bf3dacfb672d149b [ Upstream commit 09264098ff153f60866039d60b31d39b66f55a31 ] 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: Mathieu Maret <mathieu.maret@gmail.com> Signed-off-by: Brendan Shanks <bshanks@codeweavers.com> Link: https://lore.kernel.org/r/20200421231003.7935-1-bshanks@codeweavers.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 09264098ff153f60866039d60b31d39b66f55a31 ]

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: Mathieu Maret <mathieu.maret@gmail.com>
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Link: https://lore.kernel.org/r/20200421231003.7935-1-bshanks@codeweavers.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Input: usbtouchscreen - add support for BonXeon TP 2020-06-03T06:23:11+00:00 James Hilliard james.hilliard1@gmail.com 2020-04-19T04:17:12+00:00 c9d18314c930d121255ae5cd5bdd3e5a2ab37605 [ Upstream commit e3b4f94ef52ae1592cbe199bd38dbdc0d58b2217 ] 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: James 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: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit e3b4f94ef52ae1592cbe199bd38dbdc0d58b2217 ]

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: James 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: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>