On Tue, 29 Dec 2009, Oliver Neukum wrote: > I believe we can do away with hub_activate() if we do global > suspend. And this is not just the cost of resubmitting the URBs > but requesting the port status and waiting for it, because we walk > the tree top down. It sounds like you are suggesting that much of the work of resuming a hub should be pushed off into the khubd thread. This is not as simple as you seem to think; a hub needs to be operating properly before its children can be resumed. hub_activate() does one or two things which cannot be put off. For example, it checks for enabled ports which ought to be disabled. If they exist, they indicate that the firmware has messed things up; these ports need to be disabled before anything else happens. > We can simply globally resume, do the delay and assume all hubs > are still present. If not, khubd will eventually deal with it. And if the assumption is wrong (i.e., if the hubs are present but need to be reset) then the children will be lost, because reset-resume is impossible if the hub itself needs to be reset. Consider what happens during resume from hibernation. Every USB device needs to be reset and re-enumerated, and this must occur _before_ the driver's resume method is called. Hence it cannot be put off into khubd. > > Keeping URBs alive while suspending devices is a tricky game. It > > doesn't work if a device is selectively suspended, i.e., the way we do > > Yes, but why do we care? There may be reasons we need to wake > devices that were asleep when the system suspended, but does > this need to be anything but a normal autoresume, which can happen > fully asynchronous? The way I see it, keeping URBs alive while doing a bus suspend just adds unnecessary complexity without providing any comparable benefit. What's the point? > I am tempted to treat USB 3.0 as a different system in terms of power > management. It is just too different with functions as opposed to devices > sleeping. Yes, I came to the same conclusion. 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
