kernel/linux.git/drivers/hid/surface-hid, branch v6.6.132

Merge tag 'for-linus-2023022201' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid

2023-02-22T19:24:42+00:00

Pull HID updates from Benjamin Tissoires: - HID-BPF infrastructure: this allows to start using HID-BPF. Note that the mechanism to ship HID-BPF program through the kernel tree is still not implemented yet (but is planned). This should be a no-op for 99% of users. Also we are gaining kselftests for the HID tree (Benjamin Tissoires) - Some UAF fixes in workers when using uhid (Pietro Borrello & Benjamin Tissoires) - Constify hid_ll_driver (Thomas Weißschuh) - Allow more custom IIO sensors through HID (Philipp Jungkamp) - Logitech HID++ fixes for scroll wheel, protocol and debug (Bastien Nocera) - Some new device support: Steam Deck (Vicki Pfau), UClogic (José Expósito), Logitech G923 Xbox Edition steering wheel (Walt Holman), EVision keyboards (Philippe Valembois) - other assorted code cleanups and fixes * tag 'for-linus-2023022201' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: (99 commits) HID: mcp-2221: prevent UAF in delayed work hid: bigben_probe(): validate report count HID: asus: use spinlock to safely schedule workers HID: asus: use spinlock to protect concurrent accesses HID: bigben: use spinlock to safely schedule workers HID: bigben_worker() remove unneeded check on report_field HID: bigben: use spinlock to protect concurrent accesses HID: logitech-hidpp: Add myself to authors HID: logitech-hidpp: Retry commands when device is busy HID: logitech-hidpp: Add more debug statements HID: Add support for Logitech G923 Xbox Edition steering wheel HID: logitech-hidpp: Add Signature M650 HID: logitech-hidpp: Remove HIDPP_QUIRK_NO_HIDINPUT quirk HID: logitech-hidpp: Don't restart communication if not necessary HID: logitech-hidpp: Add constants for HID++ 2.0 error codes Revert "HID: logitech-hidpp: add a module parameter to keep firmware gestures" HID: logitech-hidpp: Hard-code HID++ 1.0 fast scroll support HID: i2c-hid: goodix: Add mainboard-vddio-supply dt-bindings: HID: i2c-hid: goodix: Add mainboard-vddio-supply HID: i2c-hid: goodix: Stop tying the reset line to the regulator ...

HID: surface-hid: Constify lowlevel HID driver

2023-02-06T14:08:45+00:00

Since commit 52d225346904 ("HID: Make lowlevel driver structs const") the lowlevel HID drivers are only exposed as const. Take advantage of this to constify the underlying structure, too. Signed-off-by: Thomas Weißschuh Reviewed-by: Maximilian Luz Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20230130-hid-const-ll-driver-v1-6-3fc282b3b1d0@weissschuh.net Signed-off-by: Benjamin Tissoires

platform/surface: aggregator: Rename top-level request functions to avoid ambiguities

2023-02-02T21:48:20+00:00

We currently have a struct ssam_request_sync and a function ssam_request_sync(). While this is valid C, there are some downsides to it. One of these is that current Sphinx versions (>= 3.0) cannot disambiguate between the two (see disucssion and pull request linked below). It instead emits a "WARNING: Duplicate C declaration" and links for the struct and function in the resulting documentation link to the same entry (i.e. both to either function or struct documentation) instead of their respective own entries. While we could just ignore that and wait for a fix, there's also a point to be made that the current naming can be somewhat confusing when searching (e.g. via grep) or trying to understand the levels of abstraction at play: We currently have struct ssam_request_sync and associated functions ssam_request_sync_[alloc|free|init|wait|...]() operating on this struct. However, function ssam_request_sync() is one abstraction level above this. Similarly, ssam_request_sync_with_buffer() is not a function operating on struct ssam_request_sync, but rather a sibling to ssam_request_sync(), both using the struct under the hood. Therefore, rename the top level request functions: ssam_request_sync() -> ssam_request_do_sync() ssam_request_sync_with_buffer() -> ssam_request_do_sync_with_buffer() ssam_request_sync_onstack() -> ssam_request_do_sync_onstack() Link: https://lore.kernel.org/all/085e0ada65c11da9303d07e70c510dc45f21315b.1656756450.git.mchehab@kernel.org/ Link: https://github.com/sphinx-doc/sphinx/pull/8313 Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20221220175608.1436273-2-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/surface: aggregator: Enforce use of target-ID enum in device ID macros

2023-02-02T21:48:20+00:00

Similar to the target category (TC), the target ID (TID) can be one value out of a small number of choices, given in enum ssam_ssh_tid. In the device ID macros, SSAM_SDEV() and SSAM_VDEV() we already use text expansion to, both, remove some textual clutter for the target category values and enforce that the value belongs to the known set. Now that we know the names for the target IDs, use the same trick for them as well. Also rename the SSAM_ANY_x macros to SSAM_SSH_x_ANY to better fit in. Signed-off-by: Maximilian Luz Acked-by: Sebastian Reichel Link: https://lore.kernel.org/r/20221202223327.690880-9-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

HID: surface-hid: Use target-ID enum instead of hard-coding values

2023-02-02T21:48:20+00:00

Instead of hard-coding the target ID, use the respective enum ssam_ssh_tid value. Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20221202223327.690880-8-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

HID: surface-hid: Add support for hot-removal

2022-06-13T15:25:08+00:00

Add support for hot-removal of SSAM HID client devices. Once a device has been hot-removed, further communication with it should be avoided as it may fail and time out. While the device will be removed as soon as we detect hot-removal, communication may still occur during teardown, especially when unregistering notifiers. While hot-removal is a surprise event that can happen at any time, try to avoid communication as much as possible once it has been detected to prevent timeouts that can slow down device removal and cause issues, e.g. when quickly re-attaching the device. Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20220527023447.2460025-8-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

HID: add suspend/resume helpers

2021-12-02T14:42:46+00:00

There is a lot of duplication of code in the HID low level drivers. Better have everything in one place so we can eventually extend it in a generic way. Signed-off-by: Benjamin Tissoires Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20211202095334.14399-4-benjamin.tissoires@redhat.com

HID: surface-hid: Allow driver matching for target ID 1 devices

2021-10-22T08:55:23+00:00

Until now we have only ever seen HID devices with target ID 2. The new Surface Laptop Studio however uses HID devices with target ID 1. Allow matching this driver to those as well. Cc: stable@vger.kernel.org # 5.14+ Signed-off-by: Maximilian Luz Acked-by: Benjamin Tissoires Link: https://lore.kernel.org/r/20211021130904.862610-4-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

HID: surface-hid: Use correct event registry for managing HID events

2021-10-22T08:54:51+00:00

Until now, we have only ever seen the REG-category registry being used on devices addressed with target ID 2. In fact, we have only ever seen Surface Aggregator Module (SAM) HID devices with target ID 2. For those devices, the registry also has to be addressed with target ID 2. Some devices, like the new Surface Laptop Studio, however, address their HID devices on target ID 1. As a result of this, any target ID 2 commands time out. This includes event management commands addressed to the target ID 2 REG-category registry. For these devices, the registry has to be addressed via target ID 1 instead. We therefore assume that the target ID of the registry to be used depends on the target ID of the respective device. Implement this accordingly. Note that we currently allow the surface HID driver to only load against devices with target ID 2, so these timeouts are not happening (yet). This is just a preparation step before we allow the driver to load against all target IDs. Cc: stable@vger.kernel.org # 5.14+ Signed-off-by: Maximilian Luz Acked-by: Benjamin Tissoires Link: https://lore.kernel.org/r/20211021130904.862610-3-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

HID: surface-hid: Fix get-report request

2021-06-15T08:54:51+00:00

Getting a report (e.g. feature report) from a device requires us to send a request indicating which report we want to retrieve and then waiting for the corresponding response containing that report. We already provide the response structure to the request call, but the request isn't marked as a request that expects a response. Thus the request returns before we receive the response and the response buffer indicates a zero length response due to that. This essentially means that the get-report calls are broken and will always indicate that a report of length zero has been read. Fix this by appropriately marking the request. Fixes: b05ff1002a5c ("HID: Add support for Surface Aggregator Module HID transport") Signed-off-by: Maximilian Luz Signed-off-by: Jiri Kosina