kernel/linux.git/drivers/platform/surface/aggregator/controller.c, branch v6.1.168

platform/surface: aggregator: Fix warning when controller is destroyed in probe

2024-08-29T15:30:42+00:00

[ Upstream commit bc923d594db21bee0ead128eb4bb78f7e77467a4 ] There is a small window in ssam_serial_hub_probe() where the controller is initialized but has not been started yet. Specifically, between ssam_controller_init() and ssam_controller_start(). Any failure in this window, for example caused by a failure of serdev_device_open(), currently results in an incorrect warning being emitted. In particular, any failure in this window results in the controller being destroyed via ssam_controller_destroy(). This function checks the state of the controller and, in an attempt to validate that the controller has been cleanly shut down before we try and deallocate any resources, emits a warning if that state is not SSAM_CONTROLLER_STOPPED. However, since we have only just initialized the controller and have not yet started it, its state is SSAM_CONTROLLER_INITIALIZED. Note that this is the only point at which the controller has this state, as it will change after we start the controller with ssam_controller_start() and never revert back. Further, at this point no communication has taken place and the sender and receiver threads have not been started yet (and we may not even have an open serdev device either). Therefore, it is perfectly safe to call ssam_controller_destroy() with a state of SSAM_CONTROLLER_INITIALIZED. This, however, means that the warning currently being emitted is incorrect. Fix it by extending the check. Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem") Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20240811124645.246016-1-luzmaximilian@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin

platform/surface: aggregator: Allow completion work-items to be executed in parallel

2023-06-14T09:15:15+00:00

[ Upstream commit 539e0a7f9105d19c00629c3f4da00330488e8c60 ] Currently, event completion work-items are restricted to be run strictly in non-parallel fashion by the respective workqueue. However, this has lead to some problems: In some instances, the event notifier function called inside this completion workqueue takes a non-negligible amount of time to execute. One such example is the battery event handling code (surface_battery.c), which can result in a full battery information refresh, involving further synchronous communication with the EC inside the event handler. This is made worse if the communication fails spuriously, generally incurring a multi-second timeout. Since the event completions are run strictly non-parallel, this blocks other events from being propagated to the respective subsystems. This becomes especially noticeable for keyboard and touchpad input, which also funnel their events through this system. Here, users have reported occasional multi-second "freezes". Note, however, that the event handling system was never intended to run purely sequentially. Instead, we have one work struct per EC/SAM subsystem, processing the event queue for that subsystem. These work structs were intended to run in parallel, allowing sequential processing of work items for each subsystem but parallel processing of work items across subsystems. The only restriction to this is the way the workqueue is created. Therefore, replace create_workqueue() with alloc_workqueue() and do not restrict the maximum number of parallel work items to be executed on that queue, resolving any cross-subsystem blockage. Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem") Link: https://github.com/linux-surface/linux-surface/issues/1026 Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20230525210110.2785470-1-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin

platform/surface: aggregator: Add missing call to ssam_request_sync_free()

2023-01-18T10:58:32+00:00

[ Upstream commit c965daac370f08a9b71d573a71d13cda76f2a884 ] Although rare, ssam_request_sync_init() can fail. In that case, the request should be freed via ssam_request_sync_free(). Currently it is leaked instead. Fix this. Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem") Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20221220175608.1436273-1-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin

platform/surface: Update copyright year of various drivers

2022-07-02T09:23:30+00:00

Update the copyright of various Surface drivers to the current year. Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20220624205800.1355621-4-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/surface: aggregator: Allow notifiers to avoid communication on unregistering

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

When SSAM client devices have been (physically) hot-removed, communication attempts with those devices may fail and time out. This can even extend to event notifiers, due to which timeouts may occur during device removal, slowing down that process. Add a parameter to the notifier unregister function that allows skipping communication with the EC to prevent this. Furthermore, add wrappers for registering and unregistering notifiers belonging to SSAM client devices that automatically check if the device has been marked as hot-removed and communication should be avoided. Note that non-SSAM client devices can generally not be hot-removed, so also add a convenience wrapper for those, defaulting to allow communication. Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20220527023447.2460025-4-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/surface: aggregator: Drop unnecessary variable initialization

2021-06-16T15:47:54+00:00

The status variable in ssam_controller_event_disable() is always set, no need to initialize it. Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20210604210907.25738-3-luzmaximilian@gmail.com Signed-off-by: Hans de Goede

platform/surface: aggregator: Do not return uninitialized value

2021-06-16T15:47:54+00:00

The status variable in ssam_nf_refcount_disable_free() is only set when the reference count equals zero. Otherwise, it is returned uninitialized. Fix this by always initializing status to zero. Reported-by: kernel test robot Fixes: 640ee17199e4 ("platform/surface: aggregator: Allow enabling of events without notifiers") Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20210604210907.25738-2-luzmaximilian@gmail.com Signed-off-by: Hans de Goede

platform/surface: aggregator: Update copyright

2021-06-16T15:47:53+00:00

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

platform/surface: aggregator: Allow enabling of events without notifiers

2021-06-16T15:47:53+00:00

We can already enable and disable SAM events via one of two ways: either via a (non-observer) notifier tied to a specific event group, or a generic event enable/disable request. In some instances, however, neither method may be desirable. The first method will tie the event enable request to a specific notifier, however, when we want to receive notifications for multiple event groups of the same target category and forward this to the same notifier callback, we may receive duplicate events, i.e. one event per registered notifier. The second method will bypass the internal reference counting mechanism, meaning that a disable request will disable the event regardless of any other client driver using it, which may break the functionality of that driver. To address this problem, add new functions that allow enabling and disabling of events via the event reference counting mechanism built into the controller, without needing to register a notifier. This can then be used in combination with observer notifiers to process multiple events of the same target category without duplication in the same callback function. Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20210604134755.535590-3-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/surface: aggregator: Allow registering notifiers without enabling events

2021-06-16T15:47:53+00:00

Currently, each SSAM event notifier is directly tied to one group of events. This makes sense as registering a notifier will automatically take care of enabling the corresponding event group and normally drivers only need notifications for a very limited number of events, associated with different callbacks for each group. However, there are rare cases, especially for debugging, when we want to get notifications for a whole event target category instead of just a single group of events in that category. Registering multiple notifiers, i.e. one per group, may be infeasible due to two issues: a) we might not know every event enable/disable specification as some events are auto-enabled by the EC and b) forwarding this to the same callback will lead to duplicate events as we might not know the full event specification to perform the appropriate filtering. This commit introduces observer-notifiers, which are notifiers that are not tied to a specific event group and do not attempt to manage any events. In other words, they can be registered without enabling any event group or incrementing the corresponding reference count and just act as silent observers, listening to all currently/previously enabled events based on their match-specification. Essentially, this allows us to register one single notifier for a full event target category, meaning that we can process all events of that target category in a single callback without duplication. Specifically, this will be used in the cdev debug interface to forward events to user-space via a device file from which the events can be read. Signed-off-by: Maximilian Luz Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20210604134755.535590-2-luzmaximilian@gmail.com Signed-off-by: Hans de Goede