linux-dev/drivers/platform/surface/aggregator/core.c, branch linus/master

platform/surface: aggregator: Fix initialization order when compiling as builtin module

2022-05-06T11:05:57Z

When building the Surface Aggregator Module (SAM) core, registry, and other SAM client drivers as builtin modules (=y), proper initialization order is not guaranteed. Due to this, client driver registration (triggered by device registration in the registry) races against bus initialization in the core. If any attempt is made at registering the device driver before the bus has been initialized (i.e. if bus initialization fails this race) driver registration will fail with a message similar to: Driver surface_battery was unable to register with bus_type surface_aggregator because the bus was not initialized Switch from module_init() to subsys_initcall() to resolve this issue. Note that the serdev subsystem uses postcore_initcall() so we are still able to safely register the serdev device driver for the core. Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem") Reported-by: Blaž Hrastnik Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20220429195738.535751-1-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/surface: aggregator: Make client device removal more generic

2021-11-16T09:56:54Z

Currently, there are similar functions defined in the Aggregator Registry and the controller core. Make client device removal more generic and export it. We can then use this function later on to remove client devices from device hubs as well as the controller and avoid re-defining similar things. Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20211028002243.1586083-2-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/surface: aggregator: Use serdev_acpi_get_uart_resource() helper

2021-08-13T07:13:19Z

serdev provides a generic helper to get UART Serial Bus resources. Use it instead of an open coded variant. Reviewed-by: Maximilian Luz Acked-by: Hans de Goede Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210806111736.66591-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman

Merge remote-tracking branch 'linux-pm/acpi-scan' into review-hans

2021-06-16T15:48:22Z

platform/surface: aggregator: Update copyright

2021-06-16T15:47:53Z

It's 2021, update the copyright accordingly. Signed-off-by: Maximilian Luz Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20210604134755.535590-4-luzmaximilian@gmail.com Signed-off-by: Hans de Goede

ACPI: scan: Extend acpi_walk_dep_device_list()

2021-06-07T14:45:05Z

The acpi_walk_dep_device_list() function is not as generic as its name implies, serving only to decrement the dependency count for each dependent device of the input. Extend it to accept a callback which can be applied to all the dependencies in acpi_dep_list. Replace all existing calls to the function with calls to a wrapper, passing a callback that applies the same dependency reduction. Reviewed-by: Andy Shevchenko Acked-by: Maximilian Luz # for platform/surface parts Signed-off-by: Daniel Scally [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki

platform/surface: aggregator: Add dedicated bus and device type

2021-01-06T23:06:39Z

The Surface Aggregator EC provides varying functionality, depending on the Surface device. To manage this functionality, we use dedicated client devices for each subsystem or virtual device of the EC. While some of these clients are described as standard devices in ACPI and the corresponding client drivers can be implemented as platform drivers in the kernel (making use of the controller API already present), many devices, especially on newer Surface models, cannot be found there. To simplify management of these devices, we introduce a new bus and client device type for the Surface Aggregator subsystem. The new device type takes care of managing the controller reference, essentially guaranteeing its validity for as long as the client device exists, thus alleviating the need to manually establish device links for that purpose in the client driver (as has to be done with the platform devices). Signed-off-by: Maximilian Luz Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20201221183959.1186143-7-luzmaximilian@gmail.com Signed-off-by: Hans de Goede

platform/surface: aggregator: Add trace points

2021-01-06T23:06:17Z

Add trace points to the Surface Aggregator subsystem core. These trace points can be used to track packets, requests, and allocations. They are further intended for debugging and testing/validation, specifically in combination with the error injection capabilities introduced in the subsequent commit. Signed-off-by: Maximilian Luz Reviewed-by: Hans de Goede Acked-by: Steven Rostedt (VMware) Link: https://lore.kernel.org/r/20201221183959.1186143-5-luzmaximilian@gmail.com Signed-off-by: Hans de Goede

platform/surface: aggregator: Add event item allocation caching

2021-01-06T22:45:34Z

Event items are used for completing Surface Aggregator EC events, i.e. placing event command data and payload on a workqueue for later processing to avoid doing said processing directly on the receiver thread. This means that event items are allocated for each incoming event, regardless of that event being transmitted via sequenced or unsequenced packets. On the Surface Book 3 and Surface Laptop 3, touchpad HID input events (unsequenced), can constitute a larger amount of traffic, and therefore allocation of event items. This warrants caching event items to reduce memory fragmentation. The size of the cached objects is specifically tuned to accommodate keyboard and touchpad input events and their payloads on those devices. As a result, this effectively also covers most other event types. In case of a larger event payload, event item allocation will fall back to kzalloc(). Signed-off-by: Maximilian Luz Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20201221183959.1186143-4-luzmaximilian@gmail.com Signed-off-by: Hans de Goede

platform/surface: aggregator: Add control packet allocation caching

2021-01-06T22:45:33Z

Surface Serial Hub communication is, in its core, packet based. Each sequenced packet requires to be acknowledged, via an ACK-type control packet. In case invalid data has been received by the driver, a NAK-type (not-acknowledge/negative acknowledge) control packet is sent, triggering retransmission. Control packets are therefore a core communication primitive and used frequently enough (with every sequenced packet transmission sent by the embedded controller, including events and request responses) that it may warrant caching their allocations to reduce possible memory fragmentation. Signed-off-by: Maximilian Luz Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20201221183959.1186143-3-luzmaximilian@gmail.com Signed-off-by: Hans de Goede