kernel/linux.git/drivers/input/rmi4, branch v5.4.185

Input: synaptics-rmi4 - fix error return code in rmi_driver_probe()

2020-06-03T06:21:17+00:00

[ 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 Link: https://lore.kernel.org/r/20200428134948.78343-1-weiyongjun1@huawei.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Input: synaptics-rmi4 - really fix attn_data use-after-free

2020-06-03T06:21:17+00:00

[ 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 Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200427145537.1.Ic8f898e0147beeee2c005ee7b20f1aebdef1e7eb@changeid Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Revert "Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers"

2020-01-29T15:45:27+00:00

commit 8ff771f8c8d55d95f102cf88a970e541a8bd6bcf upstream. This reverts commit a284e11c371e446371675668d8c8120a27227339. This causes problems (drifting cursor) with at least the F11 function that reads more than 32 bytes. The real issue is in the F54 driver, and so this should be fixed there, and not in rmi_smbus.c. So first revert this bad commit, then fix the real problem in F54 in another patch. Signed-off-by: Hans Verkuil Reported-by: Timo Kaufmann Fixes: a284e11c371e ("Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200115124819.3191024-2-hverkuil-cisco@xs4all.nl Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers

2019-12-13T07:42:42+00:00

commit a284e11c371e446371675668d8c8120a27227339 upstream. This increment of rmi_smbus in rmi_smb_read/write_block() causes garbage to be read/written. The first read of SMB_MAX_COUNT bytes is fine, but after that it is nonsense. Trial-and-error showed that by dropping the increment of rmiaddr everything is fine and the F54 function properly works. I tried a hack with rmi_smb_write_block() as well (writing to the same F54 touchpad data area, then reading it back), and that suggests that there too the rmiaddr increment has to be dropped. It makes sense that if it has to be dropped for read, then it has to be dropped for write as well. It looks like the initial work with F54 was done using i2c, not smbus, and it seems nobody ever tested F54 with smbus. The other functions all read/write less than SMB_MAX_COUNT as far as I can tell, so this issue was never noticed with non-F54 functions. With this change I can read out the touchpad data correctly on my Lenovo X1 Carbon 6th Gen laptop. Signed-off-by: Hans Verkuil Link: https://lore.kernel.org/r/8dd22e21-4933-8e9c-a696-d281872c8de7@xs4all.nl Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: synaptics-rmi4 - re-enable IRQs in f34v7_do_reflash

2019-12-13T07:42:41+00:00

commit 86bcd3a12999447faad60ec59c2d64d18d8e61ac upstream. F34 is a bit special as it reinitializes the device and related driver structs during the firmware update. This clears the fn_irq_mask which will then prevent F34 from receiving further interrupts, leading to timeouts during the firmware update. Make sure to reinitialize the IRQ enables at the appropriate times. The issue is in F34 code, but the commit in the fixes tag exposed the issue, as before this commit things would work by accident. Fixes: 363c53875aef (Input: synaptics-rmi4 - avoid processing unknown IRQs) Signed-off-by: Lucas Stach Link: https://lore.kernel.org/r/20191129133514.23224-1-l.stach@pengutronix.de Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: synaptics-rmi4 - destroy F54 poller workqueue when removing

2019-11-15T19:46:33+00:00

The driver forgets to destroy workqueue in remove() similarly to what is done when probe() fails. Add a call to destroy_workqueue() to fix it. Since unregistration will wait for the work to finish, we do not need to cancel/flush the work instance in remove(). Signed-off-by: Chuhong Yuan Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191114023405.31477-1-hslester96@gmail.com Signed-off-by: Dmitry Torokhov

Input: synaptics-rmi4 - clear IRQ enables for F54

2019-11-13T00:49:22+00:00

The driver for F54 just polls the status and doesn't even have a IRQ handler registered. Make sure to disable all F54 IRQs, so we don't crash the kernel on a nonexistent handler. Signed-off-by: Lucas Stach Link: https://lore.kernel.org/r/20191105114402.6009-1-l.stach@pengutronix.de Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov

Input: synaptics-rmi4 - remove unused result_bits mask

2019-11-05T00:11:51+00:00

The result_bits mask is no longer used by the driver and should be removed. Signed-off-by: Andrew Duggan Link: https://lore.kernel.org/r/20191025002527.3189-4-aduggan@synaptics.com Signed-off-by: Dmitry Torokhov

Input: synaptics-rmi4 - do not consume more data than we have (F11, F12)

2019-11-05T00:11:50+00:00

Currently, rmi_f11_attention() and rmi_f12_attention() functions update the attn_data data pointer and size based on the size of the expected size of the attention data. However, if the actual valid data in the attn buffer is less then the expected value then the updated data pointer will point to memory beyond the end of the attn buffer. Using the calculated valid_bytes instead will prevent this from happening. Signed-off-by: Andrew Duggan Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191025002527.3189-3-aduggan@synaptics.com Signed-off-by: Dmitry Torokhov

Input: synaptics-rmi4 - disable the relative position IRQ in the F12 driver

2019-11-05T00:11:48+00:00

This patch fixes an issue seen on HID touchpads which report finger positions using RMI4 Function 12. The issue manifests itself as spurious button presses as described in: https://www.spinics.net/lists/linux-input/msg58618.html Commit 24d28e4f1271 ("Input: synaptics-rmi4 - convert irq distribution to irq_domain") switched the RMI4 driver to using an irq_domain to handle RMI4 function interrupts. Functions with more then one interrupt now have each interrupt mapped to their own IRQ and IRQ handler. The result of this change is that the F12 IRQ handler was now getting called twice. Once for the absolute data interrupt and once for the relative data interrupt. For HID devices, calling rmi_f12_attention() a second time causes the attn_data data pointer and size to be set incorrectly. When the touchpad button is pressed, F30 will generate an interrupt and attempt to read the F30 data from the invalid attn_data data pointer and report incorrect button events. This patch disables the F12 relative interrupt which prevents rmi_f12_attention() from being called twice. Signed-off-by: Andrew Duggan Reported-by: Simon Wood Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191025002527.3189-2-aduggan@synaptics.com Signed-off-by: Dmitry Torokhov