- 14 Oct, 2023 4 commits
-
-
Javier Carrasco authored
syzbot has found a use-after-free bug [1] in the powermate driver. This happens when the device is disconnected, which leads to a memory free from the powermate_device struct. When an asynchronous control message completes after the kfree and its callback is invoked, the lock does not exist anymore and hence the bug. Use usb_kill_urb() on pm->config to cancel any in-progress requests upon device disconnection. [1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1eSigned-off-by:
Javier Carrasco <javier.carrasco.cruz@gmail.com> Reported-by: syzbot+0434ac83f907a1dbdd1e@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20230916-topic-powermate_use_after_free-v3-1-64412b81a7a2@gmail.comSigned-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Matthias Berndt authored
Add VID and PID to the xpad_device table to allow driver to use the PXN V900 steering wheel, which is XTYPE_XBOX360 compatible in xinput mode. Signed-off-by:
Matthias Berndt <matthias_berndt@gmx.de> Link: https://lore.kernel.org/r/4932699.31r3eYUQgx@fedoraSigned-off-by:
-
Dmitry Torokhov authored
Touch controllers need some time after receiving reset command for the firmware to finish re-initializing and be ready to respond to commands from the host. The driver already had handling for the post-reset delay for I2C and SPI transports, this change adds the handling to SMBus-connected devices. SMBus devices are peculiar because they implement legacy PS/2 compatibility mode, so reset is actually issued by psmouse driver on the associated serio port, after which the control is passed to the RMI4 driver with SMBus companion device. Note that originally the delay was added to psmouse driver in 92e24e0e ("Input: psmouse - add delay when deactivating for SMBus mode"), but that resulted in an unwanted delay in "fast" reconnect handler for the serio port, so it was decided to revert the patch and have the delay being handled in the RMI4 driver, similar to the other transports. Tested-by:
Jeffery Miller <jefferymiller@google.com> Link: https://lore.kernel.org/r/ZR1yUFJ8a9Zt606N@penguinSigned-off-by:
-
Jeffery Miller authored
When the SMBus connection is attempted psmouse_smbus_init() sets the fast_reconnect pointer to psmouse_smbus_reconnecti(). If SMBus initialization fails, elantech_setup_ps2() and synaptics_init_ps2() will fallback to PS/2 mode, replacing the psmouse private data. This can cause issues on resume, since psmouse_smbus_reconnect() expects to find an instance of struct psmouse_smbus_dev in psmouse->private. The issue was uncovered when in 92e24e0e ("Input: psmouse - add delay when deactivating for SMBus mode") psmouse_smbus_reconnect() started attempting to use more of the data structure. The commit was since reverted, not because it was at fault, but because there was found a better way of doing what it was attempting to do. Fix the problem by resetting the fast_reconnect pointer in psmouse structure in elantech_setup_ps2() and synaptics_init_ps2() when the PS/2 mode is used. Reported-by:
Thorsten Leemhuis <linux@leemhuis.info> Tested-by:
-
- 12 Oct, 2023 1 commit
-
-
Dmitry Torokhov authored
This reverts commit 92e24e0e. While the patch itself is correct, it uncovered an issue with fallback to PS/2 mode, where we were leaving psmouse->fast_reconnect handler set to psmouse_smbus_reconnect(), which caused crashes. While discussing various approaches to fix the issue it was noted that this patch ass undesired delay in the "fast" resume path of PS/2 device, and it would be better to actually use "reset_delay" option defined in struct rmi_device_platform_data and have RMI code handle it for SMBus transport as well. So this patch is being reverted to deal with crashes and a better solution will be merged shortly. Reported-by:
-
- 04 Oct, 2023 2 commits
-
-
Hans de Goede authored
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 3de93e6e ("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 <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231003215144.69527-1-hdegoede@redhat.comSigned-off-by:
-
Szilard Fabian authored
In the initial boot stage the integrated keyboard of Fujitsu Lifebook E5411 refuses to work and it's not possible to type for example a dm-crypt passphrase without the help of an external keyboard. i8042.nomux kernel parameter resolves this issue but using that a PS/2 mouse is detected. This input device is unused even when the i2c-hid-acpi kernel module is blacklisted making the integrated ELAN touchpad (04F3:308A) not working at all. Since the integrated touchpad is managed by the i2c_designware input driver in the Linux kernel and you can't find a PS/2 mouse port on the computer I think it's safe to not use the PS/2 mouse port at all. Signed-off-by:
Szilard Fabian <szfabian@bluemarch.art> Link: https://lore.kernel.org/r/20231004011749.101789-1-szfabian@bluemarch.artSigned-off-by:
-
- 18 Sep, 2023 1 commit
-
-
Max Nguyen authored
Add HyperX controller support to xpad_device and xpad_table. Suggested-by:
Chris Toledanes <chris.toledanes@hp.com> Reviewed-by:
Carl Ng <carl.ng@hp.com> Signed-off-by:
Max Nguyen <maxwell.nguyen@hp.com> Reviewed-by:
Rahul Rameshbabu <rrameshbabu@nvidia.com> Link: https://lore.kernel.org/r/20230906231514.4291-1-hphyperxdev@gmail.comSigned-off-by:
-
- 30 Aug, 2023 1 commit
-
-
Dmitry Torokhov authored
Prepare input updates for 6.6 merge window.
-
- 15 Aug, 2023 1 commit
-
-
Felix Engelhardt authored
The Goodix touchscreen controller with ACPI ID GDX9110 was not recognized by the goodix driver. This patch adds this ID to the list of supported IDs, allowing the driver to be used with this device. The change will allow Linux to be used on ~1 million tablet devices used in Kenyan primary schools. Signed-off-by:
Felix Engelhardt <felix.engelhardt@eidu.com> Reviewed-by:
-
- 01 Aug, 2023 1 commit
-
-
Ruan Jinjie authored
There is no possible for platform_get_irq() to return 0, and the return value of platform_get_irq() is more sensible to show the error reason. Signed-off-by:
Ruan Jinjie <ruanjinjie@huawei.com> Link: https://lore.kernel.org/r/20230731122246.2028651-1-ruanjinjie@huawei.comSigned-off-by:
-
- 29 Jul, 2023 11 commits
-
-
Dmitry Torokhov authored
Instead of rolling custom polling implementation use input core facilities. Link: https://lore.kernel.org/r/20230724053024.352054-5-dmitry.torokhov@gmail.comSigned-off-by:
-
Yangtao Li authored
Use devm_* api to simplify code, this makes it unnecessary to explicitly release resources. Signed-off-by:
Yangtao Li <frank.li@vivo.com> Link: https://lore.kernel.org/r/20230724053024.352054-4-dmitry.torokhov@gmail.comSigned-off-by:
-
Dmitry Torokhov authored
The driver has been switched to use IRQF_NO_AUTOEN, but in the error unwinding and remove paths calls to enable_irq() were left in place, which will lead to an incorrect enable counter value. Fixes: bcd9730a ("Input: move to use request_irq by IRQF_NO_AUTOEN flag") Link: https://lore.kernel.org/r/20230724053024.352054-3-dmitry.torokhov@gmail.comSigned-off-by:
-
Dmitry Torokhov authored
tca6416_keypad_suspend() and tca6416_keypad_resume() only configure device IRQ for wakeup. I2C core already does this by registering interrupt as a wakeup IRQ in case when device is marked as wakeup-enabled, so we can simply remove this code from the driver. Link: https://lore.kernel.org/r/20230724053024.352054-2-dmitry.torokhov@gmail.comSigned-off-by:
-
Dmitry Torokhov authored
Remove option having i2c client contain raw gpio number instead of proper IRQ number. There are no users of this facility in mainline and it will allow cleaning up the driver code with regard to wakeup handling, etc. Link: https://lore.kernel.org/r/20230724053024.352054-1-dmitry.torokhov@gmail.comSigned-off-by:
-
Yangtao Li authored
Use devm_* api to simplify code, this makes it unnecessary to explicitly release resources. Signed-off-by:
-
Dmitry Torokhov authored
Device core now has facilities to create driver-specific device attributes as part of driver probing, use them. Link: https://lore.kernel.org/r/20230724052901.350240-1-dmitry.torokhov@gmail.comSigned-off-by:
-
Yangtao Li authored
Use devm_* api to simplify code, this makes it unnecessary to explicitly release resources. Signed-off-by:
-
Dmitry Torokhov authored
Rely on the platform and ACPI/DT to set up the interrupt trigger. Link: https://lore.kernel.org/r/20230724051345.335219-3-dmitry.torokhov@gmail.comSigned-off-by:
-
Dmitry Torokhov authored
Instead of using combination of normal IRQ and work item which required careful handling on device teardown, use standard threaded interrupt that allows communication wityh the chip over slow (I2C) bus directly in the interrupt handler. To support polling mode switch to standard polling support implemented by the input core. Link: https://lore.kernel.org/r/20230724051345.335219-2-dmitry.torokhov@gmail.comSigned-off-by:
-
Dmitry Torokhov authored
i2c_check_functionality() returns essentially a boolean and not an error code, so treat it as such. Link: https://lore.kernel.org/r/20230724051345.335219-1-dmitry.torokhov@gmail.comSigned-off-by:
-
- 26 Jul, 2023 1 commit
-
-
Jeffery Miller authored
There is a period of time between the psmouse deactivate and the ability to communicate with the SMBus companion. Insert a sleep after the deactivate to account for the delay and ensure the SMBus companion is responsive. Attempting to read from the SMBus companion too quickly was causing the touchpad on machines with an i801_smbus companion to stop working after a sleep/resume cycle. On resume the rmi4_smbus would fail with errors reading the SMBus version number: ``` [5454] i2c_i801:i801_check_post:414: i801_smbus 0000:00:1f.3: No response smbus_result: i2c-0 a=02c f=0000 c=fd BYTE_DATA rd res=-6 rmi4_smbus 0-002c: failed to get SMBus version number! ... rmi4_f01 rmi4-00.fn01: Failed to restore normal operation: -6. rmi4_f01 rmi4-00.fn01: Resume failed with code -6. rmi4_physical rmi4-00: Failed to suspend functions: -6 rmi4_smbus 0-002c: Failed to resume device: -6 ``` In this case the rmi_smb_get_version fails with -ENXIO if it happens too soon after the preceding serio_resume -> psmouse_deactivate call. On boot this issue could cause the touchpad to stay in the limited PS/2 mode. This only reproduced in 1 in 10 boots on the Lenovo T440p. Failures in the log on boot would show up as: ``` psmouse serio1: synaptics: Trying to set up SMBus access [122] i2c_i801:i801_check_post:437: i801_smbus 0000:00:1f.3: No response psmouse serio1: synaptics: SMbus companion is not ready yet ``` Experimentation on the Lenovo T440p showed that a delay of 7-12ms on resume allowed the companion to respond. The 30ms delay in this patch was chosen based on the linux-input message: Link: https://lore.kernel.org/all/BYAPR03MB47572F2C65E52ED673238D41B2439@BYAPR03MB4757.namprd03.prod.outlook.com/Signed-off-by:
-
- 25 Jul, 2023 1 commit
-
-
Nathan Chancellor authored
Clang warns (or errors with CONFIG_WERROR=y): drivers/input/keyboard/mcs_touchkey.c:149:49: error: variable 'error' is uninitialized when used here [-Werror,-Wuninitialized] 149 | dev_err(&client->dev, "i2c read error[%d]\n", error); | ^~~~~ include/linux/dev_printk.h:144:65: note: expanded from macro 'dev_err' 144 | dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__) | ^~~~~~~~~~~ include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap' 110 | _p_func(dev, fmt, ##__VA_ARGS__); \ | ^~~~~~~~~~~ drivers/input/keyboard/mcs_touchkey.c:110:11: note: initialize the variable 'error' to silence this warning 110 | int error; | ^ | = 0 1 error generated. A refactoring updated the error handling in this block but did not update the dev_err() call to use fw_ver instead of error. Do so now to fix the warning and avoid printing uninitialized memory. Closes: https://github.com/ClangBuiltLinux/linux/issues/1893 Fixes: e175eae1 ("Input: mcs-touchkey - convert to use devm_* api") Signed-off-by:Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20230725-mcs_touchkey-fix-wuninitialized-v1-1-615db39af51c@kernel.orgSigned-off-by:
-
- 20 Jul, 2023 4 commits
-
-
Yangtao Li authored
Use devm_* api to simplify code, this makes it unnecessary to explicitly release resources. Signed-off-by:
-
Yangtao Li authored
Use devm_* api to simplify code, this makes it unnecessary to explicitly release resources. Signed-off-by:
-
Yangtao Li authored
Use devm_* api to simplify code, this makes it unnecessary to explicitly release resources. Signed-off-by:
-
Yangtao Li authored
Use devm_* api to simplify code, this makes it unnecessary to explicitly release resources. Signed-off-by:
-
- 19 Jul, 2023 2 commits
-
-
Artur Weber authored
MELFAS MMS114 and similar touchscreens have support for touch keys. Enable support of them in the driver. The keycodes to emit can be controlled by the linux,keycodes DT property. Sidenote - the MAX_TOUCHKEYS value is set to 15, as that's the maximum value that the ID field can contain. I don't have access to any datasheets that could confirm or deny whether this is accurate. Most downstream drivers I've been able to find only use up to 2 keys (though I did find a driver that mentioned up to 4, but only 2 were used). They don't have any checks for a maximum keycode value, it is just extracted from the ID bits (0xf mask). The drivers I've been able to find also don't use touch ID 0; I assume that it is never used, so the keycodes provided in the DT start from touch ID 1. I suppose this is in-line with the regular behavior for touch IDs in touchscreen events, as there the provided touch ID is always lowered by 1, which would cause an overflow if it was 0... Just in case, we quietly return if the touch ID is set to 0 here. The implementation of the linux,keycodes property handling code was adapted from the msg2638 driver. Signed-off-by:
Artur Weber <aweber.kernel@gmail.com> Link: https://lore.kernel.org/r/20230714100424.29798-3-aweber.kernel@gmail.comSigned-off-by:
-
Artur Weber authored
MELFAS MMS114 and similar touchscreens have support for touch keys. Add the linux,keycodes property which can be used to set up the keycodes for the touch keys. Acked-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
- 18 Jul, 2023 1 commit
-
-
Samuel Holland authored
Mark the IRQ as a wake IRQ so it will be enabled during system suspend. Signed-off-by:
Samuel Holland <samuel.holland@sifive.com> Link: https://lore.kernel.org/r/20230717192004.1304287-1-samuel.holland@sifive.comSigned-off-by:
-
- 17 Jul, 2023 3 commits
-
-
Geert Uytterhoeven authored
Use the dev_err_probe() helper, instead of open-coding the same operation. While at it, invert the error checking logic to simplify code flow. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/d225a837c50e2b19a41555a8f7ce0f94b1689aa4.1689600353.git.geert+renesas@glider.beSigned-off-by:
-
Rob Herring authored
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230714174633.4058096-1-robh@kernel.orgSigned-off-by:
-
Dmitry Torokhov authored
Sync up with mainline to bring in updates to shared infrastructure.
-
- 13 Jul, 2023 1 commit
-
-
Jeff LaBundy authored
Point the OF match table directly to the struct that describes the device as opposed to an intermediate enum; doing so simplifies the code and avoids a clang warning. As part of this change, the I2C device ID table is removed, as the device cannot probe without an OF node due to the unique nature of the hardware's interrupt pin. Fixes: f2ba47e6 ("Input: add support for Azoteq IQS7210A/7211A/E") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202307131717.LtwApG0z-lkp@intel.com/Signed-off-by:
Jeff LaBundy <jeff@labundy.com> Link: https://lore.kernel.org/r/ZLA+cuciIeVcCvm6@nixie71Signed-off-by:
-
- 12 Jul, 2023 5 commits
-
-
Jeff LaBundy authored
Add support for the Azoteq IQS7210A/7211A/E family of trackpad/ touchscreen controllers. Signed-off-by:
-
Jeff LaBundy authored
Add bindings for the Azoteq IQS7210A/7211A/E family of trackpad/ touchscreen controllers. Signed-off-by:
-
Roi L authored
devm_input_allocate_device() already assigns the @dev.parent field of the input device/structure, so there's no need to reassign input->dev.parent to dev. Signed-off-by:
Roi L <roeilev321_@outlook.com> Link: https://lore.kernel.org/r/PH0P220MB0460B69CA018F5515F5FACDDDD53A@PH0P220MB0460.NAMP220.PROD.OUTLOOK.COMSigned-off-by:
-
Werner Sembach authored
The touchpad of this device is both connected via PS/2 and i2c. This causes strange behavior when both driver fight for control. The easy fix is to prevent the PS/2 driver from accessing the mouse port as the full feature set of the touchpad is only supported in the i2c interface anyway. The strange behavior in this case is, that when an external screen is connected and the notebook is closed, the pointer on the external screen is moving to the lower right corner. When the notebook is opened again, this movement stops, but the touchpad clicks are unresponsive afterwards until reboot. Signed-off-by:
Werner Sembach <wse@tuxedocomputers.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230607173331.851192-1-wse@tuxedocomputers.comSigned-off-by:
-
Krzysztof Kozlowski authored
Pass proper PTR_ERR as dev_err_probe() argument. Fixes: a2c795b6 ("Input: bcm-keypad - simplify with dev_err_probe()") Reported-by:
Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202306261505.wTjCXRIO-lkp@intel.com/Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230711072449.43569-1-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
