On Sat, 18 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. > > True, the new code could call hcd_bus_resume and then return > > -EBUSY. I thought it was easier just to call usb_hcd_resume_root_hub > > instead. Either way ought to work. > > > Do not need to return -EBUSY? Only calling usb_hcd_resume_root_hub can quit > system pm routine? I will have a test next week, and give you result. Ooh, you're right about that. usb_hcd_resume_root_hub uses the PM workqueue, which gets frozen at the start of system suspend. Therefore it won't abort the suspend. I'll post a revised patch in a few days. 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
