> > > > This patch may not useful, as if the remote wakeup occurs before the > bus(roothub) suspend > > (taking ehic_bus_suspend as an example), the bus suspend will quit due > to there is a resume > > signal at one port. > > No, not always. For example, the wakeup event might be a disconnect > instead of a resume at some port. > For disconnect wakeup event, I think it should not forbid system to suspend. > > If the remote wakeup occurs after bus suspend, but before your patch, > > the HCD_FLAG_POLL_PENDING will not be set due to hcd->driver- > >hub_status_data returns 0 (taking > > ehci as an example), as this flag is set after 25ms later after remote > wakeup occurs. > > > > For your talked condition B: > > (B) If the event happens before the controller device is > > suspended but after the root hub is suspended, there will be a > > root-hub wakeup interrupt. The HCD's handler will call > > usb_hcd_resume_root_hub(), and again the sleep transition will > > be aborted or the root hub will autoresume. Again we're okay. > > > > It may fail for system suspend condition due to workqueue is frozen at > that time. > In fact, this kinds of problem is complicated, if the wakeup event occurs after controller suspend, the wakeup will occur, but can't stop system entering suspend. > I'm going to change the patch anyway. I'll post a new version soon. > > 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
