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 ar
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>
show more ...
|
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 e
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>
show more ...
|
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
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>
show more ...
|
35a927f2 | 10-Mar-2021 |
Maximilian Luz <luzmaximilian@gmail.com> |
HID: surface-hid: Add support for legacy keyboard interface
Add support for the legacy keyboard (KBD/TC=0x08) HID transport layer of the Surface System Aggregator Module (SSAM) to the Surface HID dr
HID: surface-hid: Add support for legacy keyboard interface
Add support for the legacy keyboard (KBD/TC=0x08) HID transport layer of the Surface System Aggregator Module (SSAM) to the Surface HID driver. On Surface Laptops 1 and 2, this interface is used to connect the integrated keyboard.
Note that this subsystem interface essentially provides a limited HID transport layer. In contrast to the generic HID interface (TC=0x15) used on newer Surface models, this interface only allows (as far as we know) for a single device to be connected and is otherwise severely limited in terms of support for feature- and output-reports. Specifically, only caps-lock-LED output-reports and a single read-only feature-report are supported.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
show more ...
|