On 2.2.2024 10.42, Guan-Yu Lin wrote:
In systems with both a main processor and a co-processor, asynchronous controller management can lead to conflicts. For example, the main processor might attempt to suspend a USB device while the co-processor is actively transferring data. To address this, we introduce a new sysfs entry, "disable_suspend2ram", which allows userspace to control the suspend-to-RAM functionality of devices on a specific USB bus. Since the userspace has visibility into the activities of both processors, it can resolve potential conflicts. Signed-off-by: Guan-Yu Lin <guanyulin@xxxxxxxxxx> ---
Doesn't setting this new disable_suspend2ram break system suspend on all other systems except this one? On any system with a PCI xHC we end up trying to suddenly stop the xHC host with all connected usb devices still fully up and running. In the xhci platform device case again nothing will be stopped or suspended, but PM framework assumes everything is suspended correctly. So then xHC either continues running and generates interrupts, or it might be abruptly powered off if the bus above it suspends. (For example if the xhci platform device is created by a PCI DWC3, and it goes to D3 state) EHCI and other hosts face similar issues with trying to suspend the controller when the devices connected to it are fully up and running. To me it looks like this whole co-processor case needs to be developed and designed into the pm framework Thanks Mathias
