Hi, On 2/12/21 12:54 PM, Maximilian Luz wrote: > The Surface System Aggregator Module (SSAM) subsystem provides various > functionalities, which are separated by spreading them across multiple > devices and corresponding drivers. Parts of that functionality / some of > those devices, however, can (as far as we currently know) not be > auto-detected by conventional means. While older (specifically 5th- and > 6th-)generation models do advertise most of their functionality via > standard platform devices in ACPI, newer generations do not. > > As we are currently also not aware of any feasible way to query said > functionalities dynamically, this poses a problem. There is, however, a > device in ACPI that seems to be used by Windows for identifying > different Surface models: The Windows Surface Integration Device (WSID). > This device seems to have a HID corresponding to the overall set of > functionalities SSAM provides for the associated model. > > This series introduces a device registry based on software nodes and > device hubs to solve this problem. The registry is intended to contain > all required non-detectable information. > > The platform hub driver is loaded against the WSID device and > instantiates and manages SSAM devices based on the information provided > by the registry for the given WSID HID of the Surface model. All new > devices created by this hub added as child devices to this hub. > > In addition, a base hub is introduced to manage devices associated with > the detachable base part of the Surface Book 3, as this requires special > handling (i.e. devices need to be removed when the base is removed). > Again, all devices created by the base hub (i.e. associated with the > base) are added as child devices to this hub. > > In total, this will yield the following device structure > > WSID > |- SSAM device 1 (physical device) > |- SSAM device 2 (physical device) > |- SSAM device 3 (physical device) > |- ... > \- SSAM base hub (virtual device) > |- SSAM base device 1 (physical device) > |- SSAM base device 2 (physical device) > |- ... > > While software nodes seem to be well suited for this approach due to > extensibility, they still need to be hard-coded, so I'm open for ideas > on how this could be improved. Thank you for your patch-series, I've applied the series to my review-hans branch: https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans Note it will show up in my review-hans branch once I've pushed my local branch there, which might take a while. Once I've run some tests on this branch the patches there will be added to the platform-drivers-x86/for-next branch and eventually will be included in the pdx86 pull-request to Linus for the next merge-window. Regards, Hans > > Changes in v2: > - Fix Kconfig dependency > > Changes in v3: > - Fix use of lockdep_assert_held() > > Maximilian Luz (6): > platform/surface: Set up Surface Aggregator device registry > platform/surface: aggregator_registry: Add base device hub > platform/surface: aggregator_registry: Add battery subsystem devices > platform/surface: aggregator_registry: Add platform profile device > platform/surface: aggregator_registry: Add DTX device > platform/surface: aggregator_registry: Add HID subsystem devices > > MAINTAINERS | 1 + > drivers/platform/surface/Kconfig | 27 + > drivers/platform/surface/Makefile | 1 + > .../surface/surface_aggregator_registry.c | 641 ++++++++++++++++++ > 4 files changed, 670 insertions(+) > create mode 100644 drivers/platform/surface/surface_aggregator_registry.c >
