On Mon, Dec 28, 2009 at 09:37:45AM -0500, Alan Stern wrote: > 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. Let me see if I understand what you're proposing. We want to suspend the entire system, which may or may not cause a loss of power to the host controller. If there's a loss of power, we need to reset the host controller and re-enumerate the devices. Currently, we selectively suspend each device in the tree, starting from the bottom and working our way to the root hub. Instead of doing that, you want to suspend the entire bus at the roothub. I think you might run into a snag with USB 3.0 hubs. Here's the quote from section 10.8 of the USB 3.0 bus spec: "Global suspend/resume refers to the entire bus being suspended or resumed without affecting any hub’s downstream facing port states; selective suspend/resume refers to a downstream facing port of a hub being suspended or resumed without affecting the hub state. SuperSpeed hubs only support selective suspend and resume. They do not support global suspend and resume." I would have to read the hub portion of the spec closely to figure out if what you're proposing is possible, but my initial reaction is that the bus spec authors didn't intend for software to globally suspend the bus on system sleep. Sarah Sharp -- 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
