BMC/Intel-BMC/linux.git/drivers/input, branch dev-5.15-intel

Merge tag 'v5.15.36' into dev-5.15

2022-04-28T01:48:30+00:00

This is the 5.15.36 stable release Signed-off-by: Joel Stanley

Input: omap4-keypad - fix pm_runtime_get_sync() error checking

2022-04-27T12:38:58+00:00

[ Upstream commit 81022a170462d38ea10612cb67e8e2c529d58abe ] If the device is already in a runtime PM enabled state pm_runtime_get_sync() will return 1, so a test for negative value should be used to check for errors. Fixes: f77621cc640a ("Input: omap-keypad - dynamically handle register offsets") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220412070131.19848-1-linmq006@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Merge tag 'v5.15.34' into dev-5.15

2022-04-14T08:19:30+00:00

This is the 5.15.34 stable release Signed-off-by: Joel Stanley

Revert "Input: clear BTN_RIGHT/MIDDLE on buttonpads"

2022-04-08T12:22:55+00:00

commit 8b188fba75195745026e11d408e4a7e94e01d701 upstream. This reverts commit 37ef4c19b4c659926ce65a7ac709ceaefb211c40. The touchpad present in the Dell Precision 7550 and 7750 laptops reports a HID_DG_BUTTONTYPE of type MT_BUTTONTYPE_CLICKPAD. However, the device is not a clickpad, it is a touchpad with physical buttons. In order to fix this issue, a quirk for the device was introduced in libinput [1] [2] to disable the INPUT_PROP_BUTTONPAD property: [Precision 7x50 Touchpad] MatchBus=i2c MatchUdevType=touchpad MatchDMIModalias=dmi:*svnDellInc.:pnPrecision7?50* AttrInputPropDisable=INPUT_PROP_BUTTONPAD However, because of the change introduced in 37ef4c19b4 ("Input: clear BTN_RIGHT/MIDDLE on buttonpads") the BTN_RIGHT key bit is not mapped anymore breaking the device right click button and making impossible to workaround it in user space. In order to avoid breakage on other present or future devices, revert the patch causing the issue. Signed-off-by: José Expósito Reviewed-by: Hans de Goede Acked-by: Peter Hutterer Acked-by: Benjamin Tissoires Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220321184404.20025-1-jose.exposito89@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: zinitix - do not report shadow fingers

2022-04-08T12:22:47+00:00

[ Upstream commit e941dc13fd3717122207d74539ab95da07ef797f ] I observed the following problem with the BT404 touch pad running the Phosh UI: When e.g. typing on the virtual keyboard pressing "g" would produce "ggg". After some analysis it turns out the firmware reports that three fingers hit that coordinate at the same time, finger 0, 2 and 4 (of the five available 0,1,2,3,4). DOWN Zinitix-TS 3-0020: finger 0 down (246, 395) Zinitix-TS 3-0020: finger 1 up (0, 0) Zinitix-TS 3-0020: finger 2 down (246, 395) Zinitix-TS 3-0020: finger 3 up (0, 0) Zinitix-TS 3-0020: finger 4 down (246, 395) UP Zinitix-TS 3-0020: finger 0 up (246, 395) Zinitix-TS 3-0020: finger 2 up (246, 395) Zinitix-TS 3-0020: finger 4 up (246, 395) This is one touch and release: i.e. this is all reported on touch (down) and release. There is a field in the struct touch_event called finger_cnt which is actually a bitmask of the fingers active in the event. Rename this field finger_mask as this matches the use contents better, then use for_each_set_bit() to iterate over just the fingers that are actally active. Factor out a finger reporting function zinitix_report_fingers() to handle all fingers. Also be more careful in reporting finger down/up: we were reporting every event with input_mt_report_slot_state(..., true); but this should only be reported on finger down or move, not on finger up, so also add code to check p->sub_status to see what is happening and report correctly. After this my Zinitix BT404 touchscreen report fingers flawlessly. The vendor drive I have notably does not use the "finger_cnt" and contains obviously incorrect code like this: if (touch_dev->touch_info.finger_cnt > MAX_SUPPORTED_FINGER_NUM) touch_dev->touch_info.finger_cnt = MAX_SUPPORTED_FINGER_NUM; As MAX_SUPPORTED_FINGER_NUM is an ordinal and the field is a bitmask this seems quite confused. Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20220228233017.2270599-1-linus.walleij@linaro.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Input: aiptek - properly check endpoint type

2022-03-23T08:16:43+00:00

commit 5600f6986628dde8881734090588474f54a540a8 upstream. Syzbot reported warning in usb_submit_urb() which is caused by wrong endpoint type. There was a check for the number of endpoints, but not for the type of endpoint. Fix it by replacing old desc.bNumEndpoints check with usb_find_common_endpoints() helper for finding endpoints Fail log: usb 5-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: usb_hub_wq hub_event ... Call Trace: aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830 input_open_device+0x1bb/0x320 drivers/input/input.c:629 kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593 Fixes: 8e20cf2bce12 ("Input: aiptek - fix crash on detecting device without endpoints") Reported-and-tested-by: syzbot+75cccf2b7da87fb6f84b@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Link: https://lore.kernel.org/r/20220308194328.26220-1-paskripkin@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Merge tag 'v5.15.30' into dev-5.15

2022-03-22T12:24:45+00:00

This is the 5.15.30 stable release Signed-off-by: Joel Stanley

Input: samsung-keypad - properly state IOMEM dependency

2022-03-08T18:12:53+00:00

commit ba115adf61b36b8c167126425a62b0efc23f72c0 upstream. Make the samsung-keypad driver explicitly depend on CONFIG_HAS_IOMEM, as it calls devm_ioremap(). This prevents compile errors in some configs (e.g, allyesconfig/randconfig under UML): /usr/bin/ld: drivers/input/keyboard/samsung-keypad.o: in function `samsung_keypad_probe': samsung-keypad.c:(.text+0xc60): undefined reference to `devm_ioremap' Signed-off-by: David Gow Acked-by: anton ivanov Link: https://lore.kernel.org/r/20220225041727.1902850-1-davidgow@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: elan_i2c - fix regulator enable count imbalance after suspend/resume

2022-03-08T18:12:53+00:00

commit 04b7762e37c95d9b965d16bb0e18dbd1fa2e2861 upstream. Before these changes elan_suspend() would only disable the regulator when device_may_wakeup() returns false; whereas elan_resume() would unconditionally enable it, leading to an enable count imbalance when device_may_wakeup() returns true. This triggers the "WARN_ON(regulator->enable_count)" in regulator_put() when the elan_i2c driver gets unbound, this happens e.g. with the hot-plugable dock with Elan I2C touchpad for the Asus TF103C 2-in-1. Fix this by making the regulator_enable() call also be conditional on device_may_wakeup() returning false. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20220131135436.29638-2-hdegoede@redhat.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: elan_i2c - move regulator_[en|dis]able() out of elan_[en|dis]able_power()

2022-03-08T18:12:53+00:00

commit 81a36d8ce554b82b0a08e2b95d0bd44fcbff339b upstream. elan_disable_power() is called conditionally on suspend, where as elan_enable_power() is always called on resume. This leads to an imbalance in the regulator's enable count. Move the regulator_[en|dis]able() calls out of elan_[en|dis]able_power() in preparation of fixing this. No functional changes intended. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20220131135436.29638-1-hdegoede@redhat.com [dtor: consolidate elan_[en|dis]able() into elan_set_power()] Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman