On Tue, Sep 20, 2011 at 12:54:16PM -0400, Alan Stern wrote: > On Fri, 16 Sep 2011, Greg KH wrote: > > > On Fri, Sep 16, 2011 at 11:55:15AM -0400, Alan Stern wrote: > > > On Fri, 16 Sep 2011, Greg KH wrote: > > > > > > > > Following the kernel's policy, USB host controllers currently are > > > > > disabled for remote wakeup by default. This really isn't what we should > > > > > do. If the user wants a USB device to wake the system then he has to > > > > > "echo enabled >/sys/.../power/wakeup" for both the device and its > > > > > controller. There's no reason to require that second step -- we lose > > > > > nothing by enabling wakeups on the controller by default. > > > > > > > > > > What do people think about this change in the policy? > > > > > > > > It makes sense to change this by default, but what does that mean for > > > > existing users? Will their systems suddenly wakeup when previously they > > > > didn't? > > > > > > As far as I can tell, the only USB devices currently enabled for remote > > > wakeup by default are keyboards and root hubs. My proposed patch would > > > disable root hubs and enable host controllers. > > > > > > As a result, the only change people should see is that (unless they or > > > their distributions deliberately alter the settings) pressing a key > > > on a USB keyboard will wake up a sleeping system whereas before it > > > would not. > > > > > > It's hard to say whether this is good or bad. I don't normally use a > > > USB keyboard, and my systems _do_ wake up when I press a key, which I > > > regard as desirable. The proposed change would make USB keyboards > > > behave the same as my PS/2 and laptop keyboards. Other people might > > > not feel the same way about it, though. > > > > I feel that is the way it should be as well, so this is good. > > > > > As for other subsystems, I can't say much. Changing the policy doesn't > > > have any immediate effect, of course -- people still have to change > > > the code. But I think it makes sense. Even for something simple like > > > PCI bridges; we obviously want bridges to forward PME# signals to the > > > CPU. > > > > Agreed. > > 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? And yeah, it is unfortunate, but it shouldn't be a big issue that I can tell. greg k-h -- 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
