On Sun, 19 Feb 2012, Chen Peter-B29397 wrote: > > > The time of resume signal is 1-15ms for remote wakeup featured device, > > > The code routine(hcd->driver->bus_suspend-> hcd->driver->bus_resume) is > > process context, > > > it will have schedule switch, I have ever met one 3G modem which only > > sends 3ms resume signal, > > > how to guarantee the above routine can be finished within 3ms? > > > > We can't guarantee it. In fact, we can't guarantee that any of the > > remote wakeup pathways in the USB stack will meet their time limits. > > > > But it doesn't matter. If the resume signal doesn't come in time, the > > device will go back to sleep. Then later on, when the resume signal > > finally does arrive, it will wake back up again. > > > It depends on device. Before the suspend, we tell device it can wakeup host > through USB_REQ_SET_FEATURE, but when it really sends wakeup signal, the host > does not act which the device has expected. It may lose some data it wants to send Host or other > uncertain situation. I think you do not want that confusing thing happen, so > you design the logic at choose_wakeup. I don't understand. The only way to avoid the problem completely is never to enable remote wakeup. We don't want that. 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
