On 24/07/23(Mon) 12:07, Mark Kettenis wrote: > Hi All, > > I recently committed a change to the xhci(4) driver that fixed an > issue with suspending a machine while it has USB devices plugged in. > Unfortunately this diff had some unintended side effects. After > looking at the way the USB stack works, I've come to the conclusion > that it is best to try and fix the drivers to self-protect against > events coming in while the device is being detached. Some drivers > already do this, some drivers only do this partially. The diff below > makes sure that all of the USB WiFi drivers do this in a consistent > way by checking that we're in the processes of detaching the devices > at the following points:
We spend quite some time in the past years trying to get rid of the usbd_is_dying() mechanism. I'm quite sad to see such diff. I've no idea what the underlying issue is and if an alternative is possible. The idea is that the USB stack should already take care of this, not every driver. Because we've seen it's hard for drivers to do that correctly. > 1. The driver's ioctl function. > > 2. The driver's USB transfer completion callbacks. Those are called by usb_transfer_complete(). This correspond to xhci_xfer_done() and xhci_event_port_change(). Does those functions need to be called during suspend? It is not clear to me what your issue is. I wish we could find a fix inside xhci(4) or the USB stack. Thanks, Martin
