summaryrefslogtreecommitdiffstats
path: root/drivers/hid/hid-logitech-hidpp.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* HID: logitech-hidpp: Do not flood kernel logOleksandr Natalenko2024-02-061-3/+10
| | | | | | | | | | | | | | | | | | | Since commit 680ee411a98e ("HID: logitech-hidpp: Fix connect event race") the following messages appear in the kernel log from time to time: logitech-hidpp-device 0003:046D:408A.0005: HID++ 4.5 device connected. logitech-hidpp-device 0003:046D:408A.0005: HID++ 4.5 device connected. logitech-hidpp-device 0003:046D:4051.0006: Disconnected logitech-hidpp-device 0003:046D:408A.0005: Disconnected As discussed, print the first per-device "device connected" message at info level, demoting subsequent messages to debug level. Also, demote the "Disconnected message" to debug level unconditionally. Link: https://lore.kernel.org/lkml/3277085.44csPzL39Z@natalenko.name/ Signed-off-by: Oleksandr Natalenko <oleksandr@natalenko.name> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
* HID: logitech-hidpp: add support for Logitech G Pro X Superlight 2Jiri Kosina2024-01-221-0/+2
| | | | | | | Let logitech-hidpp driver claim Logitech G Pro X Superlight 2. Reported-by: Marcus Rückert <darix@opensu.se> Signed-off-by: Jiri Kosina <jkosina@suse.com>
* HID: logitech-hidpp: Stop IO before calling hid_connect()Hans de Goede2023-10-261-3/+6
| | | | | | | | | | | | | | | | | hid_connect() will call hid_pidff_init() which does hid_device_io_start() leading to an "io already started" warning. To fix this call hid_device_io_stop() before calling hid_connect(), stopping IO means that connect events may be lost while hid_connect() runs, re-enable IO and move the hidpp_connect_event() work queuing after the hid_connect(). Note re-enabling IO is also necessary for the g920_get_config() call later during hidpp_probe(). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231025190151.302376-1-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: Drop HIDPP_QUIRK_UNIFYINGHans de Goede2023-10-251-10/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | HIDPP unifying is only checked once in probe() and it is also set by probe() itself. Drop the quirk and replace its one check by the condition which is used to set the quirk in the first place. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-13-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: Drop delayed_work_cb()Hans de Goede2023-10-251-11/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drop delayed_work_cb() instead make hidpp_connect_event() the workqueue function itself. Besides resulting in a small cleanup this will hopefully also make it clearer that going forward hidpp_connect_event() should only be run from a workqueue and not be directly invoked. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-12-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: Fix connect event raceHans de Goede2023-10-251-20/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a connect event race in hidpp_probe() in these 2 lines: connected = hidpp_root_get_protocol_version(hidpp) == 0; atomic_set(&hidpp->connected, connected); Specifically the following can happen: 1. This line from hidpp_probe() is executed: connected = hidpp_root_get_protocol_version(hidpp) == 0; and sets connected to false; 2. A connect-event packet is received and does: atomic_set(&hidpp->connected, true); 3. The next line from hidpp_probe() is executed: atomic_set(&hidpp->connected, connected); and sets the atomic_t back to 0 again. 4. hidpp_connect_event() runs and sees the connected device as disconnected because of this. To fix this make hidpp_connect_event() query the connection status of the device itself instead of having it rely on possibly stale data cached in struct hidpp_device. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-11-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: Remove unused connected param from *_connect()Hans de Goede2023-10-251-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the unused connected function parameter from wtp_connect(), m560_send_config_command() and k400_connect(). This is a preparation patch for moving all connected state handling to hidpp_connect_event(). This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-10-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: Remove connected check for non-unifying devicesHans de Goede2023-10-251-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Non-unifying devices (USB, Bluetooth) are always connected during probe(), remove the unnecessary connected check. This is a preparation patch for moving all connected state handling to hidpp_connect_event(). This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-9-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: Add hidpp_non_unifying_init() helperHans de Goede2023-10-251-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Turn hidpp_overwrite_name() into a hidpp_non_unifying_init() helper which takes care of setting both the name and the serial for non unifying devices. This mirrors the hidpp_unifying_init() helper for unifying devices. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-8-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: Move hidpp_overwrite_name() to before connect checkHans de Goede2023-10-251-13/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the hidpp_overwrite_name() call to before the connect check, this puts it at the same place in the probe() order as hidpp_serial_init() which seems more logical. This should not make a difference since this is in the non-unifying path and only unifying devices can be probed in non-connected state. This is a preparation patch for moving all connected state handling to hidpp_connect_event(). Doing this before the connect check requires dropping the protocol version check since protocol_major is not set yet now. Instead this relies on hidpp_root_get_feature(HIDPP_PAGE_GET_DEVICE_NAME_TYPE) failing on older devices, just like how hidpp_get_serial() relies on hidpp_root_get_feature(HIDPP_PAGE_DEVICE_INFORMATION) failing on older devices. So this again makes the code more consistent. Also stop printing an error on failure now, since with the proto version check gone failures are expected to happen on older devices. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-7-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: Move g920_get_config() to just before hidpp_ff_init()Hans de Goede2023-10-251-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The data retrieved by g920_get_config() is only used by hidpp_ff_init(). Now that the hw is kept open till the end of probe() the g920_get_config() call can be moved to just before hidpp_ff_init() to have all the HIDPP_QUIRK_CLASS_G920 together in a single place. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-6-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: Remove wtp_get_config() call from probe()Hans de Goede2023-10-251-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For WTP devices which start disconnected (paired with the unifying receiver, but not connected atm) hidpp_connect_event() takes care of calling wtp_get_config() when the device later connects. There is no need to have a separate code path for WTP devices which are connected at probe() time, these can use the same code-path since probe() will queue hidpp_connect_event() for those at probe time. Drop the unnecessary wtp_get_config() call from probe(). This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-5-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: Move get_wireless_feature_index() check to ↵Hans de Goede2023-10-251-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | hidpp_connect_event() Calling get_wireless_feature_index() from probe() causes the wireless_feature_index to only get set for unifying devices which are already connected at probe() time. It does not get set for devices which connect later. Fix this by moving get_wireless_feature_index() to hidpp_connect_event(), this does not make a difference for devices connected at probe() since probe() will queue the hidpp_connect_event() for those at probe time. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Fixes: 0da0a63b7cba ("HID: logitech-hidpp: Support WirelessDeviceStatus connect events") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-4-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: Revert "Don't restart communication if not necessary"Hans de Goede2023-10-251-16/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 91cf9a98ae41 ("HID: logitech-hidpp: make .probe usbhid capable") makes hidpp_probe() first call hid_hw_start(hdev, 0) to allow IO without connecting any hid subdrivers (hid-input, hidraw). This is done to allow to retrieve the device's name and serial number and store these in hdev->name and hdev->uniq. Then later on IO was stopped and started again with hid_hw_start(hdev, HID_CONNECT_DEFAULT) connecting hid-input and hidraw after the name and serial number have been setup. Commit 498ba2069035 ("HID: logitech-hidpp: Don't restart communication if not necessary") changed the probe() code to only do the start with a 0 connect-mask + restart later for unifying devices. But for non unifying devices hdev->name and hdev->uniq are updated too. So this change re-introduces the problem for which the start with a 0 connect-mask + restart later behavior was introduced. The previous patch in this series changes the unifying path to instead of restarting IO only call hid_connect() later. This avoids possible issues with restarting IO seen on non unifying devices. Revert the change to limit the restart behavior to unifying devices to fix hdev->name changing after userspace facing devices have already been registered. This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Fixes: 498ba2069035 ("HID: logitech-hidpp: Don't restart communication if not necessary") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-3-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: Don't restart IO, instead defer hid_connect() onlyHans de Goede2023-10-251-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Restarting IO causes 2 problems: 1. Some devices do not like IO being restarted this was addressed in commit 498ba2069035 ("HID: logitech-hidpp: Don't restart communication if not necessary"), but that change has issues of its own and needs to be reverted. 2. Restarting IO and specifically calling hid_device_io_stop() causes received packets to be missed, which may cause connect-events to get missed. Restarting IO was introduced in commit 91cf9a98ae41 ("HID: logitech-hidpp: make .probe usbhid capable") to allow to retrieve the device's name and serial number and store these in hdev->name and hdev->uniq before connecting any hid subdrivers (hid-input, hidraw) exporting this info to userspace. But this does not require restarting IO, this merely requires deferring calling hid_connect(). Calling hid_hw_start() with a connect-mask of 0 makes it skip calling hid_connect(), so hidpp_probe() can simply call hid_connect() later without needing to restart IO. Remove the stop + restart of IO and instead just call hid_connect() later to avoid the issues caused by restarting IO. Now that IO is no longer stopped, hid_hw_close() must be called at the end of probe() to balance the hid_hw_open() done at the beginning probe(). This series has been tested on the following devices: Logitech Bluetooth Laser Travel Mouse (bluetooth, HID++ 1.0) Logitech M720 Triathlon (bluetooth, HID++ 4.5) Logitech M720 Triathlon (unifying, HID++ 4.5) Logitech K400 Pro (unifying, HID++ 4.1) Logitech K270 (eQUAD nano Lite, HID++ 2.0) Logitech M185 (eQUAD nano Lite, HID++ 4.5) Logitech LX501 keyboard (27 Mhz, HID++ builtin scroll-wheel, HID++ 1.0) Logitech M-RAZ105 mouse (27 Mhz, HID++ extra mouse buttons, HID++ 1.0) And by bentiss: Logitech Touchpad T650 (unifying) Logitech Touchpad T651 (bluetooth) Logitech MX Master 3B (BLE) Logitech G403 (plain USB / Gaming receiver) Fixes: 498ba2069035 ("HID: logitech-hidpp: Don't restart communication if not necessary") Suggested-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231010102029.111003-2-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: Fix kernel crash on receiver USB disconnectHans de Goede2023-10-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: power_supply_unregister+0x8e/0xa0 Sep 22 20:01:35 eric kernel: release_nodes+0x3d/0xb0 Sep 22 20:01:35 eric kernel: devres_release_group+0xfc/0x130 Sep 22 20:01:35 eric kernel: hid_device_remove+0x56/0xa0 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? __queue_work+0x1df/0x440 Sep 22 20:01:35 eric kernel: hid_destroy_device+0x4b/0x60 Sep 22 20:01:35 eric kernel: logi_dj_remove+0x9a/0x100 [hid_logitech_dj 5c91534a0ead2b65e04dd799a0437e3b99b21bc4] Sep 22 20:01:35 eric kernel: hid_device_remove+0x44/0xa0 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? __queue_work+0x1df/0x440 Sep 22 20:01:35 eric kernel: hid_destroy_device+0x4b/0x60 Sep 22 20:01:35 eric kernel: usbhid_disconnect+0x47/0x60 [usbhid 727dcc1c0b94e6b4418727a468398ac3bca492f3] Sep 22 20:01:35 eric kernel: usb_unbind_interface+0x90/0x270 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? kobject_put+0xa0/0x1d0 Sep 22 20:01:35 eric kernel: usb_disable_device+0xcd/0x1e0 Sep 22 20:01:35 eric kernel: usb_disconnect+0xde/0x2c0 Sep 22 20:01:35 eric kernel: usb_disconnect+0xc3/0x2c0 Sep 22 20:01:35 eric kernel: hub_event+0xe80/0x1c10 There have been quite a few bug reports (see Link tags) about this crash. Fix all the TOCTOU issues, including the really bad power-supply related system crash on USB disconnect, by making probe() use the workqueue for running hidpp_connect_event() too, so that it can never run more then once. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227221 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2242189 Link: https://bugzilla.kernel.org/show_bug.cgi?id=217412#c58 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231005182638.3776-1-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: Add Bluetooth ID for the Logitech M720 Triathlon mouseHans de Goede2023-09-181-0/+2
| | | | | | | | | Using hidpp for the M720 adds battery info reporting and hires scrolling support. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-hidpp: rework one more time the retries attemptsBenjamin Tissoires2023-08-251-40/+75
| | | | | | | | | | | | | | Extract the internal code inside a helper function, fix the initialization of the parameters used in the helper function (`hidpp->answer_available` was not reset and `*response` wasn't either), and use a `do {...} while();` loop. Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy") Cc: stable@vger.kernel.org Reviewed-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20230621-logitech-fixes-v2-1-3635f7f9c8af@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: Add support for Logitech MX Anywhere 3 mouseMaxim Mikityanskiy2023-08-141-0/+2
| | | | | | | | | | Add Logitech MX Anywhere 3 connected over Bluetooth to the device table to get hidpi scroll supported. USB connection over the Unifying receiver is already supported by the wildcard entry LDJ_DEVICE(HID_ANY_ID). Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com> Reviewed-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-hidpp: Add support for the Pro X SuperlightMavroudis Chatzilazaridis2023-08-141-0/+2
| | | | | | | | | | | This patch adds support for the Pro X Superlight over wired USB. The device now reports the status of its battery. Co-developed-by: Filipe Laíns <lains@riseup.net> Signed-off-by: Filipe Laíns <lains@riseup.net> Signed-off-by: Mavroudis Chatzilazaridis <mavchatz@protonmail.com> Reviewed-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-hidpp: Rename HID++ "internal" error constantBastien Nocera2023-08-141-1/+1
| | | | | | | | | | | | As per the upstream "hidpp" helpers commit: " There has been some confusion about error value 5 but feature specs that refer to it generally use NOT_ALLOWED. " Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://github.com/mrubli2/hidpp/commit/80c3fecfcd89c5efe0f16feabe90a55ddfd25aaa Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-hidpp: Add wired USB id for Logitech G502 LightspeedStuart Hayhurst2023-07-091-0/+2
| | | | | | | | | | | | | | | | | | | | Previously, support for the G502 had been attempted in commit '27fc32fd9417 ("HID: logitech-hidpp: add USB PID for a few more supported mice")' This caused some issues and was reverted by 'addf3382c47c ("Revert "HID: logitech-hidpp: add USB PID for a few more supported mice"")'. Since then, a new version of this mouse has been released (Lightpseed Wireless), and works correctly. This device has support for battery reporting with the driver Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com> Reviewed-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230630113818.13005-1-stuart.a.hayhurst@gmail.com Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
* HID: logitech-hidpp: add HIDPP_QUIRK_DELAYED_INIT for the T651.Mike Hommey2023-06-191-1/+1
| | | | | | | | | | | | commit 498ba2069035 ("HID: logitech-hidpp: Don't restart communication if not necessary") put restarting communication behind that flag, and this was apparently necessary on the T651, but the flag was not set for it. Fixes: 498ba2069035 ("HID: logitech-hidpp: Don't restart communication if not necessary") Cc: stable@vger.kernel.org Signed-off-by: Mike Hommey <mh@glandium.org> Link: https://lore.kernel.org/r/20230617230957.6mx73th4blv7owqk@glandium.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
* HID: logitech-hidpp: Add USB and Bluetooth IDs for the Logitech G915 TKL ↵stuarthayhurst2023-06-081-0/+4
| | | | | | | | | | | Keyboard Adds the USB and Bluetooth IDs for the Logitech G915 TKL keyboard, for device detection For this device, this provides battery reporting on top of hid-generic Reviewed-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: hidpp: terminate retry loop on successBenjamin Tissoires2023-06-051-7/+6
| | | | | | | | | | | | | | It seems we forgot the normal case to terminate the retry loop, making us asking 3 times each command, which is probably a little bit too much. And remove the ugly "goto exit" that can be replaced by a simpler "break" Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy") Suggested-by: Mark Lord <mlord@pobox.com> Tested-by: Mark Lord <mlord@pobox.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-hidpp: Handle timeout differently from busyBastien Nocera2023-05-311-0/+1
| | | | | | | | | | | | | | | | | | | If an attempt at contacting a receiver or a device fails because the receiver or device never responds, don't restart the communication, only restart it if the receiver or device answers that it's busy, as originally intended. This was the behaviour on communication timeout before commit 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy"). This fixes some overly long waits in a critical path on boot, when checking whether the device is connected by getting its HID++ version. Signed-off-by: Bastien Nocera <hadess@hadess.net> Suggested-by: Mark Lord <mlord@pobox.com> Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217412 Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-hidpp: Set wireless_status for G935 receiverBastien Nocera2023-04-031-1/+25
| | | | | | | | | | | | Set the USB interface "wireless_status" for the G935 receiver when receiving battery notifications. This will allow sound daemons such as Pipewire or PulseAudio to know whether or not the headset is turned on and connected. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230302105555.51417-6-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
* HID: logitech-hidpp: Add Logitech G935 headsetBastien Nocera2023-04-031-0/+3
| | | | | | | | | Add the Logitech G935 headset that uses the HID++ protocol to the list of supported devices. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230302105555.51417-3-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
* HID: logitech-hidpp: Add support for ADC measurement featureBastien Nocera2023-04-031-2/+170
| | | | | | | | | | | | This is used in a number of Logitech headsets to report the voltage of the battery. Tested on a Logitech G935. Signed-off-by: Bastien Nocera <hadess@hadess.net> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216483 Link: https://lore.kernel.org/r/20230302105555.51417-2-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
* HID: logitech-hidpp: Simplify array length checkBastien Nocera2023-04-031-3/+1
| | | | | | | | | Use the compiler to force a 100-length array, rather than check the length after the fact. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230302105555.51417-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
* HID: logitech-hidpp: Reconcile USB and Unifying serialsBastien Nocera2023-04-031-4/+2
| | | | | | | | | | | | | | | | | Now that USB HID++ devices can gather a serial number that matches the one that would be gathered when connected through a Unifying receiver, remove the last difference by dropping the product ID as devices usually have different product IDs when connected through USB or Unifying. For example, on the serials on a G903 wired/wireless mouse: - Unifying before patch: 4067-e8-ce-cd-45 - USB before patch: c086-e8-ce-cd-45 - Unifying and USB after patch: e8-ce-cd-45 Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230302130117.3975-2-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
* HID: logitech-hidpp: Don't use the USB serial for USB devicesBastien Nocera2023-04-031-0/+51
| | | | | | | | | | | | | | | | | | For devices that support the 0x0003 feature (Device Information) version 4, set the serial based on the output of that feature, rather than relying on the usbhid code setting the USB serial. This should allow the serial when connected through USB to (nearly) match the one when connected through a unifying receiver. For example, on the serials on a G903 wired/wireless mouse: - Unifying: 4067-e8-ce-cd-45 - USB before patch: 017C385C3837 - USB after patch: c086-e8-ce-cd-45 Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230302130117.3975-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
* HID: logitech-hidpp: Add support for Logitech MX Master 3S mouseRafał Szalecki2023-03-031-0/+2
| | | | | | | | Add signature for the Logitech MX Master 3S mouse over Bluetooth. Signed-off-by: Rafał Szalecki <perexist7@gmail.com> Reviewed-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* Merge branch 'for-6.3/logitech' into for-linusBenjamin Tissoires2023-02-221-61/+91
|\ | | | | | | | | - HID++ fixes for scroll wheel, protocol and debug (Bastien Nocera) - add support of Logitech G923 Xbox Edition steering wheel (Walt Holman)
| * HID: logitech-hidpp: Add myself to authorsBastien Nocera2023-02-151-0/+1
| | | | | | | | | | | | | | | | | | As discussed with HID maintainer Benjamin Tissoires, add myself to the authors list and MAINTAINERS file. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230209154916.462158-2-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
| * HID: logitech-hidpp: Retry commands when device is busyBastien Nocera2023-02-151-24/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Handle the busy error coming from the device or receiver. The documentation says a busy error can be returned when: " Device (or receiver) cannot answer immediately to this request for any reason i.e: - already processing a request from the same or another SW - pipe full " Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230209154916.462158-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
| * HID: logitech-hidpp: Add more debug statementsBastien Nocera2023-02-101-3/+14
| | | | | | | | | | | | | | | | This should help us figure out some hairy problems with some devices. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230206221256.129198-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
| * HID: Add support for Logitech G923 Xbox Edition steering wheelWalt Holman2023-02-101-0/+3
| | | | | | | | | | | | | | | | We get the same level of features as the regular G920. Signed-off-by: Walt Holman <waltholman09@gmail.com> Link: https://lore.kernel.org/r/20230207195051.16373-1-waltholman09@gmail.com Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
| * HID: logitech-hidpp: Add Signature M650Bastien Nocera2023-02-101-0/+2
| | | | | | | | | | | | | | | | | | | | Add support for HID++ over Bluetooth for the Logitech Signature M650 mouse. It comes with a dongle but can also be used over Bluetooth without one. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20220404100311.3304-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
| * HID: logitech-hidpp: Remove HIDPP_QUIRK_NO_HIDINPUT quirkBastien Nocera2023-02-101-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | HIDPP_QUIRK_NO_HIDINPUT isn't used by any devices but still happens to work as HIDPP_QUIRK_DELAYED_INIT is defined to the same value. Remove HIDPP_QUIRK_NO_HIDINPUT and use HIDPP_QUIRK_DELAYED_INIT everywhere instead. Tested on a T650 which requires that quirk, and a number of unifying and Bluetooth devices that don't. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230125121723.3122-2-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
| * HID: logitech-hidpp: Don't restart communication if not necessaryBastien Nocera2023-02-101-12/+20
| | | | | | | | | | | | | | | | | | Don't stop and restart communication with the device unless we need to modify the connect flags used because of a device quirk. Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20230125121723.3122-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
| * HID: logitech-hidpp: Add constants for HID++ 2.0 error codesBastien Nocera2023-02-101-0/+10
| | | | | | | | | | | | | | | | | | | | Add constants for HID++ 2.0 error codes listed in "Protocol HID++2.0 essential features" chapter, page 3, in logitech_hidpp_2.0_specification_draft_2012-06-04.pdf Signed-off-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20221207100033.64095-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
| * Revert "HID: logitech-hidpp: add a module parameter to keep firmware gestures"Bastien Nocera2023-02-101-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we're in 2022, and the majority of desktop environments can and should support touchpad gestures through libinput, remove the legacy module parameter that made it possible to use gestures implemented in firmware. This will eventually allow simplifying the driver's initialisation code. This reverts commit 9188dbaed68a4b23dc96eba165265c08caa7dc2a. Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20221220154345.474596-1-hadess@hadess.net
| * HID: logitech-hidpp: Hard-code HID++ 1.0 fast scroll supportBastien Nocera2023-02-101-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | HID++ 1.0 devices only export whether Fast Scrolling is enabled, not whether they are capable of it. Reinstate the original quirks for the 3 supported mice so fast scrolling works again on those devices. Fixes: 908d325e1665 ("HID: logitech-hidpp: Detect hi-res scrolling support") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216903 Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20230116130937.391441-1-hadess@hadess.net
* | HID: logitech: Disable hi-res scrolling on USBBastien Nocera2023-02-061-1/+2
|/ | | | | | | | | | | | | | | | | | | | On some Logitech mice, such as the G903, and possibly the G403, the HID events are generated on a different interface to the HID++ one. If we enable hi-res through the HID++ interface, the HID interface wouldn't know anything about it, and handle the events as if they were regular scroll events, making the mouse unusable. Disable hi-res scrolling on those devices until we implement scroll events through HID++. Signed-off-by: Bastien Nocera <hadess@hadess.net> Tested-by: Tobias Klausmann <klausman@schwarzvogel.de> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216885 Fixes: 908d325e1665 ("HID: logitech-hidpp: Detect hi-res scrolling support") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230203101800.139380-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
* HID: logitech-hidpp: Guard FF init code against non-USB devicesBastien Nocera2022-12-191-2/+9
| | | | | | | | | | | | | The Force Feedback code assumes that all the devices passed to it will be USB devices, but that might not be the case for emulated devices. Guard against a crash by checking the device type before poking at USB properties. Cc: stable@vger.kernel.org # v5.16+ Reported-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20221215154416.111704-1-hadess@hadess.net
* Merge branch 'for-6.2/logitech' into for-linusJiri Kosina2022-12-131-1/+1
|\ | | | | | | - always send SwID in GetProtocolVersion for Logitech HID++ (Andreas Bergmeier)
| * HID: logitech HID++: Send SwID in GetProtocolVersionAndreas Bergmeier2022-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | According to docs a SwID should be sent for GetProtocolVersion. > 0x10.DeviceIndex.0x00.0x1n where n is SwID. Signed-off-by: Andreas Bergmeier <abergmeier@gmx.net> Reviewed-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | Revert "HID: logitech-hidpp: Enable HID++ for all the Logitech Bluetooth ↵Benjamin Tissoires2022-12-081-19/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | devices" This reverts commit 532223c8ac57605a10e46dc0ab23dcf01c9acb43. As reported in [0], hid-logitech-hidpp now binds on all bluetooth mice, but there are corner cases where hid-logitech-hidpp just gives up on the mouse. This leads the end user with a dead mouse. Given that we are at -rc8, we are definitively too late to find a proper fix. We already identified 2 issues less than 24 hours after the bug report. One in that ->match() was never designed to be used anywhere else than in hid-generic, and the other that hid-logitech-hidpp has corner cases where it gives up on devices it is not supposed to. So we have no choice but postpone this patch to the next kernel release. [0] https://lore.kernel.org/linux-input/CAJZ5v0g-_o4AqMgNwihCb0jrwrcJZfRrX=jv8aH54WNKO7QB8A@mail.gmail.com/ Reported-by: Rafael J . Wysocki <rjw@rjwysocki.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | Revert "HID: logitech-hidpp: Remove special-casing of Bluetooth devices"Benjamin Tissoires2022-12-081-0/+9
|/ | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 8544c812e43ab7bdf40458411b83987b8cba924d. We need to revert commit 532223c8ac57 ("HID: logitech-hidpp: Enable HID++ for all the Logitech Bluetooth devices") because that commit might make hid-logitech-hidpp bind on mice that are not well enough supported by hid-logitech-hidpp, and the end result is that the probe of those mice is now returning -ENODEV, leaving the end user with a dead mouse. Given that commit 8544c812e43a ("HID: logitech-hidpp: Remove special-casing of Bluetooth devices") is a direct dependency of 532223c8ac57, revert it too. Note that this also adapt according to commit 908d325e1665 ("HID: logitech-hidpp: Detect hi-res scrolling support") to re-add support of the devices that were removed from that commit too. I have locally an MX Master and I tested this device with that revert, ensuring we still have high-res scrolling. Reported-by: Rafael J . Wysocki <rjw@rjwysocki.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-29 20:48:22 +0100