On Tue, 20 Sep 2011, Greg KH wrote: > > There is one drawback to the new arrangement. Many desktop and laptop > > systems have a lot more USB host controllers than ever get used. (My > > dsektop computer has 8 controllers, and I don't think there has ever > > been more than 3 USB devices plugged in at any time.) The unused root > > hubs naturally get put into runtime suspend -- and of course, they are > > enabled for remote wakeup so that they will respond when a device is > > plugged in. > > > > With the proposed changes, root hubs will disabled for wakeup during > > system sleep. That means when the system is going into suspend, the > > root hubs will have to be woken up from runtime suspend in order to > > disable remote wakeup, and then put back into suspend. This will slow > > the suspend process down a little (not too much if async suspend is > > being used, because the various root hubs can be handled in parallel). > > > > It's unfortunate, but I don't see any reasonable way around it. > > I doubt that really takes any noticeable amount of time, does it? A quick test showed that on my system, it needed an extra 130 ms or so. > And yeah, it is unfortunate, but it shouldn't be a big issue that I can > tell. One other thing turned up during testing. UHCI doesn't make any distinction between local wakeup events (devices being plugged in or unplugged) and wakeup requests received from downstream devices. There's no way to enable one without enabling the other. Currently the default situation is to enable wakeup for root hubs but leave it disabled for controllers. As a result, if people want a USB keyboard plugged into a UHCI controller to be able to wake up the system, they must manually (or via an automatic script) enable wakeup on the controller. With the proposed change in place, the situation would be just the opposite. By default we would enable wakeup for controllers but not for root hubs. That works fine for EHCI, because EHCI knows to treat local wakeup events differently from downstream requests. (I haven't been able to test OHCI yet.) But UHCI doesn't, which means that if people want to use a USB keyboard plugged into a UHCI controller to wake up the system, they will now have to manually enable wakeup on the root hub. It's no more work than the current situation, but it is a change -- the manual operation will have to be done on the root hub instead of on the controller. In theory we could leave wakeup enabled by default for UHCI root hubs. I don't think that would be a good idea, though. It would mean that unplugging the keyboard from your suspended system would cause the system to wake up. That would be a big change in behavior. 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
