2010/3/8 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > During system sleep, remote wakeup is supposed to be enabled if > device_may_wakeup() gives a nonzero value. But runtime suspend > (autosuspend) is different; remote wakeup is supposed to be enabled > whenever the device supports it. > > Currently usbcore uses device_may_wakeup() for both, so I'm going to > make some changes. At the same time, we might want to be a little more > discriminating: I think it makes sense to avoid enabling remote wakeup > if none of the interface drivers want it (i.e., if > intf->needs_remote_wakeup isn't set for any of the interfaces). > > Is there any reason not to do this? It would avoid getting spurious > wakeups from devices that shouldn't be sending them, like the > gspca-m5602 cameras that have been causing problems on various ALi > systems. > > A related matter has to do with initial wakeup settings. Currently > remote wakeup is enabled by default for all USB devices that support > it. Doesn't it make more sense to leave wakeup disabled by default and > rely on userspace to enable it only where it is needed? > > In general, external hubs probably don't need remote wakeup during > system sleep. External hubs will always relay a wakeup request > received from downstream, even if the hub's own wakeup setting is > turned off. The wakeup setting only affects whether the hub reports > connect, disconnect, and overcurrent events. Most people don't > want to know about these things while their computer is asleep. (For > example, if you suspend your computer and then unplug a USB mouse, you > don't want the unplug event to wake up the machine.) > > The most important exception is root hubs; they work slightly > differently from external hubs and I wouldn't change their current > behavior. Another exception would be USB keyboards; they should be > enabled for remote wakeup by default, as should all keyboards. I don't > know about mice -- it would depend on whether the mouse sends wakeup > requests for movement as opposed to button presses, and we have no way > to know how a mouse will behave. I'm inclined to make the default be > disabled. > > Any objections? I've now been able to verify this bug on my ALi m5602 equipped machine. Feel free to cc me on any experimental patch you want tested. Best regards, Erik > > 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
