kernel/linux.git/drivers/platform/surface/aggregator, 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: fix recv_buf() return value

2023-12-13T17:39:20+00:00

commit c8820c92caf0770bec976b01fa9e82bb993c5865 upstream. Serdev recv_buf() callback is supposed to return the amount of bytes consumed, therefore an int in between 0 and count. Do not return negative number in case of issue, when ssam_controller_receive_buf() returns ESHUTDOWN just returns 0, e.g. no bytes consumed, this keep the exact same behavior as it was before. This fixes a potential WARN in serdev-ttyport.c:ttyport_receive_buf(). Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem") Cc: stable@vger.kernel.org Signed-off-by: Francesco Dolcini Reviewed-by: Maximilian Luz Link: https://lore.kernel.org/r/20231128194935.11350-1-francesco@dolcini.it Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman

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 fwnode_handle_put()

2023-04-06T10:10:43+00:00

[ Upstream commit acd0acb802b90f88d19ad4337183e44fd0f77c50 ] In fwnode_for_each_child_node(), we should add fwnode_handle_put() when break out of the iteration fwnode_for_each_child_node() as it will automatically increase and decrease the refcounter. Fixes: fc622b3d36e6 ("platform/surface: Set up Surface Aggregator device registry") Signed-off-by: Liang He Reviewed-by: Maximilian Luz Link: https://lore.kernel.org/r/20230322033057.1855741-1-windhl@126.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: aggregator: Ignore command messages not intended for us

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

commit ae0fa0a3126a86c801c3220fcd8eefe03aa39f3e upstream. It is possible that we (the host/kernel driver) receive command messages that are not intended for us. Ignore those for now. The whole story is a bit more complicated: It is possible to enable debug output on SAM, which is sent via SSH command messages. By default this output is sent to a debug connector, with its own target ID (TID=0x03). It is possible to override the target of the debug output and set it to the host/kernel driver. This, however, does not change the original target ID of the message. Meaning, we receive messages with TID=0x03 (debug) but expect to only receive messages with TID=0x00 (host). The problem is that the different target ID also comes with a different scope of request IDs. In particular, these do not follow the standard event rules (i.e. do not fall into a set of small reserved values). Therefore, current message handling interprets them as responses to pending requests and tries to match them up via the request ID. However, these debug output messages are not in fact responses, and therefore this will at best fail to find the request and at worst pass on the wrong data as response for a request. Therefore ignore any command messages not intended for us (host) for now. We can implement support for the debug messages once we have a better understanding of them. Note that this may also provide a bit more stability and avoid some driver confusion in case any other targets want to talk to us in the future, since we don't yet know what to do with those as well. A warning for the dropped messages should suffice for now and also give us a chance of discovering new targets if they come along without any potential for bugs/instabilities. Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem") Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20221202223327.690880-2-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman

platform/surface: aggregator: Do not check for repeated unsequenced packets

2022-11-15T16:18:26+00:00

Currently, we check any received packet whether we have already seen it previously, regardless of the packet type (sequenced / unsequenced). We do this by checking the sequence number. This assumes that sequence numbers are valid for both sequenced and unsequenced packets. However, this assumption appears to be incorrect. On some devices, the sequence number field of unsequenced packets (in particular HID input events on the Surface Pro 9) is always zero. As a result, the current retransmission check kicks in and discards all but the first unsequenced packet, breaking (among other things) keyboard and touchpad input. Note that we have, so far, only seen packets being retransmitted in sequenced communication. In particular, this happens when there is an ACK timeout, causing the EC (or us) to re-send the packet waiting for an ACK. Arguably, retransmission / duplication of unsequenced packets should not be an issue as there is no logical condition (such as an ACK timeout) to determine when a packet should be sent again. Therefore, remove the retransmission check for unsequenced packets entirely to resolve the issue. Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem") Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20221113185951.224759-1-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

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: Move device registry helper functions to core module

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

Move helper functions for client device registration to the core module. This simplifies addition of future DT/OF support and also allows us to split out the device hub drivers into their own module. At the same time, also improve device node validation a bit by not silently skipping devices with invalid device UID specifiers. Further, ensure proper lifetime management for the firmware/software nodes associated with the added devices. Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20220624205800.1355621-2-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede

platform/surface: aggregator: Reserve more event- and target-categories

2022-06-22T10:06:28+00:00

With the introduction of the Surface Laptop Studio, more event- and target categories have been added. Therefore, increase the number of reserved events and extend the enum of know target categories to accommodate this. Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20220614194117.4118897-1-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede