Hi, > - not flushing the endpoints of actively offloaded USB devices. Given > that the USB devices is used by another entity, unilaterally flush > the endpoint might lead to unexpected behavior on another entity. This doesn't seem right, because flushing applies to URBs managed by the kernel, so it should have no effect on offloaded endpoints. As far as I understand from your earlier discussion with Alan Stern, the real reason is that it disrupted operation of class drivers, in particular causing kernel-managed interrupt endpoints not to be polled during suspend and some events were being lost. Or maybe the real problem was that if the INT IN endpoint isn't being polled, device events don't trigger xHCI IRQs that wake up the CPU? And by the way, usb_hcd_flush_endpoint() doc states that no new URBs may be submitted during this call. I wonder if this can be guaranteed if the interface has not been suspended first? Perhaps this alone is good reason not to flush. Regards, Michal
