user/sven/linux.git/drivers/input/touchscreen, branch v5.10.245

Input: goodix - use the new soc_intel_is_byt() helper

2024-10-17T13:07:58Z

commit d176708ffc20332d1c730098d2b111e0b77ece82 upstream. Use the new soc_intel_is_byt() helper from linux/platform_data/x86/soc.h. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20220131143539.109142-5-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov [Ricardo: Resolved minor cherry-pick conflict. The file linux/regulator/ consumer.h is not #included in the upstream version but it is in v5.10.y. ] Signed-off-by: Ricardo Neri Signed-off-by: Greg Kroah-Hartman

Input: ads7846 - ratelimit the spi_sync error message

2024-10-17T13:07:32Z

[ Upstream commit ccbfea78adf75d3d9e87aa739dab83254f5333fa ] In case the touch controller is not connected, this message keeps scrolling on the console indefinitelly. Ratelimit it to avoid filling kernel logs. " ads7846 spi2.1: spi_sync --> -22 " Signed-off-by: Marek Vasut Link: https://lore.kernel.org/r/20240708211913.171243-1-marex@denx.de Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Input: silead - Always support 10 fingers

2024-07-27T08:40:17Z

[ Upstream commit 38a38f5a36da9820680d413972cb733349400532 ] When support for Silead touchscreens was orginal added some touchscreens with older firmware versions only supported 5 fingers and this was made the default requiring the setting of a "silead,max-fingers=10" uint32 device-property for all touchscreen models which do support 10 fingers. There are very few models with the old 5 finger fw, so in practice the setting of the "silead,max-fingers=10" is boilerplate which needs to be copy and pasted to every touchscreen config. Reporting that 10 fingers are supported on devices which only support 5 fingers doesn't cause any problems for userspace in practice, since at max 4 finger gestures are supported anyways. Drop the max_fingers configuration and simply always assume 10 fingers. Signed-off-by: Hans de Goede Acked-by: Dmitry Torokhov Link: https://lore.kernel.org/r/20240525193854.39130-2-hdegoede@redhat.com Signed-off-by: Sasha Levin

Input: ili210x - fix ili251x_read_touch_data() return value

2024-07-05T07:12:46Z

[ Upstream commit 9f0fad0382124e7e23b3c730fa78818c22c89c0a ] The caller of this function treats all non-zero values as an error, so the return value of i2c_master_recv() cannot be returned directly. This fixes touch reporting when there are more than 6 active touches. Fixes: ef536abd3afd1 ("Input: ili210x - define and use chip operations structure") Signed-off-by: John Keeping Link: https://lore.kernel.org/r/20240523085624.2295988-1-jkeeping@inmusicbrands.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Input: goodix - ensure int GPIO is in input for gpio_count == 1 && gpio_int_idx == 0 case

2023-10-25T09:54:16Z

commit 423622a90abb243944d1517b9f57db53729e45c4 upstream. Add a special case for gpio_count == 1 && gpio_int_idx == 0 to goodix_add_acpi_gpio_mappings(). It seems that on newer x86/ACPI devices the reset and irq GPIOs are no longer listed as GPIO resources instead there is only 1 GpioInt resource and _PS0 does the whole reset sequence for us. This means that we must call acpi_device_fix_up_power() on these devices to ensure that the chip is reset before we try to use it. This part was already fixed in commit 3de93e6ed2df ("Input: goodix - call acpi_device_fix_up_power() in some cases") by adding a call to acpi_device_fix_up_power() to the generic "Unexpected ACPI resources" catch all. But it turns out that this case on some hw needs some more special handling. Specifically the firmware may bootup with the IRQ pin in output mode. The reset sequence from ACPI _PS0 (executed by acpi_device_fix_up_power()) should put the pin in input mode, but the GPIO subsystem has cached the direction at bootup, causing request_irq() to fail due to gpiochip_lock_as_irq() failure: [ 9.119864] Goodix-TS i2c-GDIX1002:00: Unexpected ACPI resources: gpio_count 1, gpio_int_idx 0 [ 9.317443] Goodix-TS i2c-GDIX1002:00: ID 911, version: 1060 [ 9.321902] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/0000:00:17.0/i2c_designware.4/i2c-5/i2c-GDIX1002:00/input/input8 [ 9.327840] gpio gpiochip0: (INT3453:00): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ [ 9.327856] gpio gpiochip0: (INT3453:00): unable to lock HW IRQ 26 for IRQ [ 9.327861] genirq: Failed to request resources for GDIX1002:00 (irq 131) on irqchip intel-gpio [ 9.327912] Goodix-TS i2c-GDIX1002:00: request IRQ failed: -5 Fix this by adding a special case for gpio_count == 1 && gpio_int_idx == 0 which adds an ACPI GPIO lookup table for the int GPIO even though we cannot use it for reset purposes (as there is no reset GPIO). Adding the lookup will make the gpiod_int = gpiod_get(..., GPIOD_IN) call succeed, which will explicitly set the direction to input fixing the issue. Note this re-uses the acpi_goodix_int_first_gpios[] lookup table, since there is only 1 GPIO in the ACPI resources the reset entry in that lookup table will amount to a no-op. Reported-and-tested-by: Michael Smith <1973.mjsmith@gmail.com> Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20231003215144.69527-1-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe

2023-05-17T09:48:03Z

[ Upstream commit 5bca3688bdbc3b58a2894b8671a8e2378efe28bd ] rpi_firmware_get() take reference, we need to release it in error paths as well. Use devm_rpi_firmware_get() helper to handling the resources. Also remove the existing rpi_firmware_put(). Fixes: 0b9f28fed3f7 ("Input: add official Raspberry Pi's touchscreen driver") Fixes: 3b8ddff780b7 ("input: raspberrypi-ts: Release firmware handle when not needed") Signed-off-by: Miaoqian Lin Reviewed-by: Mattijs Korpershoek Link: https://lore.kernel.org/r/20221223074657.810346-1-linmq006@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

input: raspberrypi-ts: Release firmware handle when not needed

2023-05-17T09:48:02Z

[ Upstream commit 3b8ddff780b7d12e99ae39177f84b9003097777a ] There is no use for the firmware interface after getting the touch buffer address, so release it. Signed-off-by: Nicolas Saenz Julienne Acked-by: Dmitry Torokhov Reviewed-by: Florian Fainelli Stable-dep-of: 5bca3688bdbc ("Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe") Signed-off-by: Sasha Levin

Input: goodix - add Lenovo Yoga Book X90F to nine_bytes_report DMI table

2023-04-05T09:23:49Z

commit 8a0432bab6ea3203d220785da7ab3c7677f70ecb upstream. The Android Lenovo Yoga Book X90F / X90L uses the same goodix touchscreen with 9 bytes touch reports for its touch keyboard as the already supported Windows Lenovo Yoga Book X91F/L, add a DMI match for this to the nine_bytes_report DMI table. When the quirk for the X91F/L was initially added it was written to also apply to the X90F/L but this does not work because the Android version of the Yoga Book uses completely different DMI strings. Also adjust the X91F/L quirk to reflect that it only applies to the X91F/L models. Signed-off-by: Hans de Goede Reviewed-by: Bastien Nocera Link: https://lore.kernel.org/r/20230315134442.71787-1-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: ads7846 - don't check penirq immediately for 7845

2023-03-11T15:39:43Z

[ Upstream commit fa9f4275b20ec7b2a8fb05c66362d10b36f9efec ] To discard false readings, one should use "ti,penirq-recheck-delay-usecs". Checking get_pendown_state() at the beginning, most of the time fails causing malfunctioning. Fixes: ffa458c1bd9b ("spi: ads7846 driver") Signed-off-by: Luca Ellero Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20230126105227.47648-4-l.ellero@asem.it Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Input: ads7846 - always set last command to PWRDOWN

2023-03-11T15:39:43Z

[ Upstream commit 13f82ca3878db8284a70ef9711d7f710a31eb562 ] Controllers that report pressure (e.g. ADS7846) use 5 commands and the correct sequence is READ_X, READ_Y, READ_Z1, READ_Z2, PWRDOWN. Controllers that don't report pressure (e.g. ADS7845/ADS7843) use only 3 commands and the correct sequence should be READ_X, READ_Y, PWRDOWN. But the sequence sent was incorrect: READ_X, READ_Y, READ_Z1. Fix this by setting the third (and last) command to PWRDOWN. Fixes: ffa458c1bd9b ("spi: ads7846 driver") Signed-off-by: Luca Ellero Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20230126105227.47648-3-l.ellero@asem.it Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin