user/sven/linux.git/drivers/hid, branch v6.1.85

HID: amd_sfh: Avoid disabling the interrupt

2024-03-26T22:20:51Z

[ Upstream commit c1db0073212ef39d5a46c2aea5e49bf884375ce4 ] HP ProBook x360 435 G7 using older version of firmware which doesn't support disabling the interrupt for all commands. Hence avoid disabling the interrupt for that particular model. Link: https://bugzilla.kernel.org/show_bug.cgi?id=218104 Fixes: b300667b33b2 ("HID: amd_sfh: Disable the interrupt for all command") Co-developed-by: Akshata MukundShetty Signed-off-by: Akshata MukundShetty Signed-off-by: Basavaraj Natikar Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: amd_sfh: Update HPD sensor structure elements

2024-03-26T22:20:51Z

[ Upstream commit bbf0dec30696638b8bdc28cb2f5bf23f8d760b52 ] HPD sensor data is not populating properly because of wrong order of HPD sensor structure elements. So update the order of structure elements to match the HPD sensor data received from the firmware. Fixes: 24a31ea94922 ("HID: amd_sfh: Add initial support for HPD sensor") Co-developed-by: Akshata MukundShetty Signed-off-by: Akshata MukundShetty Signed-off-by: Basavaraj Natikar Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: lenovo: Add middleclick_workaround sysfs knob for cptkbd

2024-03-26T22:20:45Z

[ Upstream commit 2814646f76f8518326964f12ff20aaee70ba154d ] Previous attempt to autodetect well-behaving patched firmware introduced in commit 46a0a2c96f0f ("HID: lenovo: Detect quirk-free fw on cptkbd and stop applying workaround") has shown that there are false-positives on original firmware (on both 1st gen and 2nd gen keyboards) which causes the middle button click workaround to be mistakenly disabled. This commit adds explicit parameter to sysfs to control this workaround. Fixes: 46a0a2c96f0f ("HID: lenovo: Detect quirk-free fw on cptkbd and stop applying workaround") Fixes: 43527a0094c1 ("HID: lenovo: Restrict detection of patched firmware only to USB cptkbd") Signed-off-by: Mikhail Khvainitski Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: multitouch: Add required quirk for Synaptics 0xcddc device

2024-03-26T22:20:25Z

[ Upstream commit 1741a8269e1c51fa08d4bfdf34667387a6eb10ec ] Add support for the pointing stick (Accupoint) and 2 mouse buttons. Present on some Toshiba/dynabook Portege X30 and X40 laptops. It should close https://bugzilla.kernel.org/show_bug.cgi?id=205817 Signed-off-by: Manuel Fombuena Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: wacom: Do not register input devices until after hid_hw_start

2024-02-23T08:12:33Z

commit c1d6708bf0d3dd976460d435373cf5abf21ce258 upstream. If a input device is opened before hid_hw_start is called, events may not be received from the hardware. In the case of USB-backed devices, for example, the hid_hw_start function is responsible for filling in the URB which is submitted when the input device is opened. If a device is opened prematurely, polling will never start because the device will not have been in the correct state to send the URB. Because the wacom driver registers its input devices before calling hid_hw_start, there is a window of time where a device can be opened and end up in an inoperable state. Some ARM-based Chromebooks in particular reliably trigger this bug. This commit splits the wacom_register_inputs function into two pieces. One which is responsible for setting up the allocated inputs (and runs prior to hid_hw_start so that devices are ready for any input events they may end up receiving) and another which only registers the devices (and runs after hid_hw_start to ensure devices can be immediately opened without issue). Note that the functions to initialize the LEDs and remotes are also moved after hid_hw_start to maintain their own dependency chains. Fixes: 7704ac937345 ("HID: wacom: implement generic HID handling for pen generic devices") Cc: stable@vger.kernel.org # v3.18+ Suggested-by: Dmitry Torokhov Signed-off-by: Jason Gerecke Tested-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: wacom: generic: Avoid reporting a serial of '0' to userspace

2024-02-23T08:12:33Z

commit ab41a31dd5e2681803642b6d08590b61867840ec upstream. The xf86-input-wacom driver does not treat '0' as a valid serial number and will drop any input report which contains an MSC_SERIAL = 0 event. The kernel driver already takes care to avoid sending any MSC_SERIAL event if the value of serial[0] == 0 (which is the case for devices that don't actually report a serial number), but this is not quite sufficient. Only the lower 32 bits of the serial get reported to userspace, so if this portion of the serial is zero then there can still be problems. This commit allows the driver to report either the lower 32 bits if they are non-zero or the upper 32 bits otherwise. Signed-off-by: Jason Gerecke Signed-off-by: Tatsunosuke Tobita Fixes: f85c9dc678a5 ("HID: wacom: generic: Support tool ID and additional tool types") CC: stable@vger.kernel.org # v4.10 Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: i2c-hid-of: fix NULL-deref on failed power up

2024-02-23T08:12:33Z

commit 00aab7dcb2267f2aef59447602f34501efe1a07f upstream. A while back the I2C HID implementation was split in an ACPI and OF part, but the new OF driver never initialises the client pointer which is dereferenced on power-up failures. Fixes: b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are separate modules") Cc: stable@vger.kernel.org # 5.12 Cc: Douglas Anderson Signed-off-by: Johan Hovold Reviewed-by: Douglas Anderson Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: hidraw: fix a problem of memory leak in hidraw_release()

2024-02-05T20:13:00Z

[ Upstream commit a3bdcdd022c68942a774e8e63424cc11c85aab78 ] 'struct hidraw_list' is a circular queue whose head can be smaller than tail. Using 'list->tail != list->head' to release all memory that should be released. Fixes: a5623a203cff ("HID: hidraw: fix memory leak in hidraw_release()") Signed-off-by: Su Hui Reviewed-by: Dan Carpenter Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: wacom: Correct behavior when processing some confidence == false touches

2024-01-25T23:27:44Z

commit 502296030ec6b0329e00f9fb15018e170cc63037 upstream. There appear to be a few different ways that Wacom devices can deal with confidence: 1. If the device looses confidence in a touch, it will first clear the tipswitch flag in one report, and then clear the confidence flag in a second report. This behavior is used by e.g. DTH-2452. 2. If the device looses confidence in a touch, it will clear both the tipswitch and confidence flags within the same report. This behavior is used by some AES devices. 3. If the device looses confidence in a touch, it will clear *only* the confidence bit. The tipswitch bit will remain set so long as the touch is tracked. This behavior may be used in future devices. The driver does not currently handle situation 3 properly. Touches that loose confidence will remain "in prox" and essentially frozen in place until the tipswitch bit is finally cleared. Not only does this result in userspace seeing a stuck touch, but it also prevents pen arbitration from working properly (the pen won't send events until all touches are up, but we don't currently process events from non-confident touches). This commit centralizes the checking of the confidence bit in the wacom_wac_finger_slot() function and has 'prox' depend on it. In the case where situation 3 is encountered, the treat the touch as though it was removed, allowing both userspace and the pen arbitration to act normally. Signed-off-by: Tatsunosuke Tobita Signed-off-by: Ping Cheng Signed-off-by: Jason Gerecke Fixes: 7fb0413baa7f ("HID: wacom: Use "Confidence" flag to prevent reporting invalid contacts") Cc: stable@vger.kernel.org Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: nintendo: Prevent divide-by-zero on code

2024-01-20T10:50:09Z

[ Upstream commit 6eb04ca8c52e3f8c8ea7102ade81d642eee87f4a ] It was reported [0] that adding a generic joycon to the system caused a kernel crash on Steam Deck, with the below panic spew: divide error: 0000 [#1] PREEMPT SMP NOPTI [...] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0119 10/24/2023 RIP: 0010:nintendo_hid_event+0x340/0xcc1 [hid_nintendo] [...] Call Trace: [...] ? exc_divide_error+0x38/0x50 ? nintendo_hid_event+0x340/0xcc1 [hid_nintendo] ? asm_exc_divide_error+0x1a/0x20 ? nintendo_hid_event+0x307/0xcc1 [hid_nintendo] hid_input_report+0x143/0x160 hidp_session_run+0x1ce/0x700 [hidp] Since it's a divide-by-0 error, by tracking the code for potential denominator issues, we've spotted 2 places in which this could happen; so let's guard against the possibility and log in the kernel if the condition happens. This is specially useful since some data that fills some denominators are read from the joycon HW in some cases, increasing the potential for flaws. [0] https://github.com/ValveSoftware/SteamOS/issues/1070 Signed-off-by: Guilherme G. Piccoli Tested-by: Sam Lantinga Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin