> > > 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. BR, Peter -- 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
