linux/drivers/input/mouse, branch v6.8

Revert "Input: bcm5974 - check endpoint type before starting traffic"

2024-03-05T17:16:08Z

This patch intended to fix an well-knonw issue in old drivers where the endpoint type is taken for granted, which is often triggered by fuzzers. That was the case for this driver [1], and although the fix seems to be correct, it uncovered another issue that leads to a regression [2], if the endpoints of the current interface are checked. The driver makes use of endpoints that belong to a different interface rather than the one it binds (it binds to the third interface, but also accesses an endpoint from a different one). The driver should claim the interfaces it requires, but that is still not the case. Given that the regression is more severe than the issue found by syzkaller, the best approach is reverting the patch that causes the regression, and trying to fix the underlying problem before checking the endpoint types again. Note that reverting this patch will probably trigger the syzkaller bug at some point. This reverts commit 2b9c3eb32a699acdd4784d6b93743271b4970899. Link: https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622 [1] Link: https://lore.kernel.org/linux-input/87sf161jjc.wl-tiwai@suse.de/ [2] Fixes: 2b9c3eb32a69 ("Input: bcm5974 - check endpoint type before starting traffic") Reported-by: Jacopo Radice Closes: https://bugzilla.suse.com/show_bug.cgi?id=1220030 Signed-off-by: Javier Carrasco Link: https://lore.kernel.org/r/20240305-revert_bcm5974_ep_check-v3-1-527198cf6499@gmail.com Signed-off-by: Dmitry Torokhov

Input: bcm5974 - check endpoint type before starting traffic

2024-01-31T18:32:59Z

syzbot has found a type mismatch between a USB pipe and the transfer endpoint, which is triggered by the bcm5974 driver[1]. This driver expects the device to provide input interrupt endpoints and if that is not the case, the driver registration should terminate. Repros are available to reproduce this issue with a certain setup for the dummy_hcd, leading to an interrupt/bulk mismatch which is caught in the USB core after calling usb_submit_urb() with the following message: "BOGUS urb xfer, pipe 1 != type 3" Some other device drivers (like the appletouch driver bcm5974 is mainly based on) provide some checking mechanism to make sure that an IN interrupt endpoint is available. In this particular case the endpoint addresses are provided by a config table, so the checking can be targeted to the provided endpoints. Add some basic checking to guarantee that the endpoints available match the expected type for both the trackpad and button endpoints. This issue was only found for the trackpad endpoint, but the checking has been added to the button endpoint as well for the same reasons. Given that there was never a check for the endpoint type, this bug has been there since the first implementation of the driver (f89bd95c5c94). [1] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622 Fixes: f89bd95c5c94 ("Input: bcm5974 - add driver for Macbook Air and Pro Penryn touchpads") Signed-off-by: Javier Carrasco Reported-and-tested-by: syzbot+348331f63b034f89b622@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20231007-topic-bcm5974_bulk-v3-1-d0f38b9d2935@gmail.com Signed-off-by: Dmitry Torokhov

Merge branch 'next' into for-linus

2024-01-14T05:54:39Z

Prepare input updates for 6.8 merge window.

Input: navpoint - convert to use GPIO descriptor

2023-12-14T05:26:13Z

The Navpoint driver uses a GPIO line, convert this to use a GPIO descriptor. There are no in-kernel users but out of tree users can easily be added or converted using a GPIO descriptor table as with numerous other drivers. Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20231129-descriptors-input-v1-1-9433162914a3@linaro.org Signed-off-by: Dmitry Torokhov

Input: mouse - use sysfs_emit[_at]() instead of scnprintf()

2023-12-14T05:26:11Z

Replace the calls to various *printf() functions with sysfs_emit() to simplify the code. Signed-off-by: ye xingchen Link: https://lore.kernel.org/r/202212021453578171100@zte.com.cn Signed-off-by: Dmitry Torokhov

Input: amimouse - convert to platform remove callback returning void

2023-12-01T23:36:18Z

The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20231201133747.1099286-2-u.kleine-koenig@pengutronix.de Signed-off-by: Dmitry Torokhov

Input: psmouse - enable Synaptics InterTouch for ThinkPad L14 G1

2023-11-15T16:52:02Z

Observed on dmesg of my laptop I see the following output: [ 19.898700] psmouse serio1: synaptics: queried max coordinates: x [..5678], y [..4694] [ 19.936057] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1162..] [ 19.936076] psmouse serio1: synaptics: Your touchpad (PNP: LEN0411 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org. [ 20.008901] psmouse serio1: synaptics: Touchpad model: 1, fw: 10.32, id: 0x1e2a1, caps: 0xf014a3/0x940300/0x12e800/0x500000, board id: 3471, fw id: 2909640 [ 20.008925] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0 [ 20.053344] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input7 [ 20.397608] mousedev: PS/2 mouse device common for all mice This patch will add its pnp id to the smbus list to produce the setup of intertouch for the device. Signed-off-by: José Pekkarinen Link: https://lore.kernel.org/r/20231114063607.71772-1-jose.pekkarinen@foxhound.fi Signed-off-by: Dmitry Torokhov

Merge branch 'next' into for-linus

2023-11-06T23:42:08Z

Prepare input updates for 6.7 merge window.

Input: synaptics-rmi4 - handle reset delay when using SMBus trsnsport

2023-10-14T00:59:19Z

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 92e24e0e57f7 ("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 Link: https://lore.kernel.org/r/ZR1yUFJ8a9Zt606N@penguin Signed-off-by: Dmitry Torokhov

Input: psmouse - fix fast_reconnect function for PS/2 mode

2023-10-14T00:59:18Z

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 92e24e0e57f7 ("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 Tested-by: Thorsten Leemhuis Signed-off-by: Jeffery Miller Fixes: bf232e460a35 ("Input: psmouse-smbus - allow to control psmouse_deactivate") Link: https://lore.kernel.org/r/20231005002249.554877-1-jefferymiller@google.com Signed-off-by: Dmitry Torokhov