#
b09ee1cd |
|
20-Dec-2022 |
Maximilian Luz <luzmaximilian@gmail.com> |
platform/surface: aggregator: Rename top-level request functions to avoid ambiguities 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 <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20221220175608.1436273-2-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
#
78abf1b5 |
|
02-Dec-2022 |
Maximilian Luz <luzmaximilian@gmail.com> |
platform/surface: aggregator: Enforce use of target-ID enum in device ID macros 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 <luzmaximilian@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20221202223327.690880-9-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
#
ab5fe339 |
|
21-Oct-2021 |
Maximilian Luz <luzmaximilian@gmail.com> |
HID: surface-hid: Allow driver matching for target ID 1 devices 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 <luzmaximilian@gmail.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211021130904.862610-4-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
#
dc0fd0ac |
|
21-Oct-2021 |
Maximilian Luz <luzmaximilian@gmail.com> |
HID: surface-hid: Use correct event registry for managing HID events 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 <luzmaximilian@gmail.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211021130904.862610-3-luzmaximilian@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
#
2b2bcc76 |
|
08-Jun-2021 |
Maximilian Luz <luzmaximilian@gmail.com> |
HID: surface-hid: Fix get-report request 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 <luzmaximilian@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
b05ff100 |
|
10-Mar-2021 |
Maximilian Luz <luzmaximilian@gmail.com> |
HID: Add support for Surface Aggregator Module HID transport Add a HID transport driver to support integrated HID devices on newer Microsoft Surface models (specifically 7th-generation, i.e. Surface Laptop 3, Surface Book 3, and later). On those models, the internal keyboard and touchpad (as well as some other HID devices with currently unknown function) are connected via the generic HID subsystem (TC=0x15) of the Surface System Aggregator Module (SSAM). This subsystem provides a generic HID transport layer, support for which is implemented by this driver. Co-developed-by: Blaž Hrastnik <blaz@mxxn.io> Signed-off-by: Blaž Hrastnik <blaz@mxxn.io> Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|