On Fri, Oct 18, 2024 at 07:59:00PM +0800, Guan-Yu Lin wrote: > Thanks for the suggestions, let me address them in the next version. > After some local development, our experiments suggest it may be > necessary to skip usb_suspend_interface() & usb_hcd_flush_endpoint() > for connection changes behind a hub and HID events in our scenario. > > Typically, when the system sleeps, the hub uses remote wakeup to > reactivate upstream devices and resume the interface to handle > connection changes. However, our current conclusion is to maintain the > device in an active state while suspending the interface. This > deviates from the norm, as remote wakeup is designed to function when > devices and links are suspended. We're concerned that this discrepancy > might interfere with the remote wakeup mechanism. > To address this, we're currently bypassing usb_suspend_interface() and > usb_hcd_flush_endpoint(). This effectively simulates an "active > system" state, allowing the USB controller to notify the kernel about > connection changes via interrupts. This workaround applies to HID > events as well. > > Which approach do you recommend? Should we invest in integrating with > the remote wakeup framework, or is it acceptable to keep necessary > components active, mirroring an "active system" state? It's hard to answer those questions because I don't have a clear idea of how the sideband system is meant to work. For instance, what does the sideband system do when a port-connect change is detected in a hub that sits between the computer and the audio device? If the sideband system decides to change the audio device's settings, how does the regular audio driver learn about the change? And so on. It's worth pointing out that allowing two different drivers to control the same device is generally not a good idea. More likely than not they will end up interfering with each other at some stage. Alan Stern
