On Mon, 28 Dec 2009, Oliver Neukum wrote: > > I don't see any benefit to your patch. Instead of having a > > "supports_transparent_suspend" flag, why not just have suspend and > > resume routines that do nothing? > > True, the flag is stupid. Still some support from the core is needed as > drivers cannot know whether they can safely let IO run. How about this? I'm not at all sure this is worth doing. It simplifies things to assume that there are no outstanding URBs when a device is suspended. See also the calls to usb_hcd_flush_endpoint() in usb_suspend_both(). Besides, the amount of time spent killing and resubmitting URBs is relatively small. What ends up eating all the time is resetting controllers and re-enumerating devices, plus the normal suspend/resume delays defined by the USB spec. We can't avoid the need for resets or re-enumeration when the controller loses power, but the other delays can be minimized by suspending the entire bus as a single operation instead of suspending each device individually. Then there's only one set of delays instead of a set for each device. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
