>What you're really saying is that we need to improve the way we handle >the race between suspending a root hub and receiving a remote wakeup on >one of its ports. The way we do it now, the remote wakeup event can >get lost. >You are right. I haven't had time to write a patch, but I think we need >to do something like this at the start of ehci_bus_suspend: > First, write 0 to the intr_enable register. This will > prevent us from seeing any future wakeup events. Isn't spin_lock_irq sufficient to disable interrupts? > Next, if any ports are in the middle of a resume sequence > (reset_done[port] is nonzero), we have to wait for the > resumes to finish and handle all the post-resume actions. There is a while loop trying to suspend all ports. Can we also check for RESUME bit here, if any port is in the middle of resuming (or reset_done[port] is nonzero), return -EBUSY and give up the current global suspend? > Then go ahead with suspending the root hub and re-enabling > interrupt requests. If there is any port resuming while we try to make a global suspend, shouldn't we let the resume to continue and quit suspending? The driver can always try suspending again at a later time. > Finally at the end, if we did encounter any in-progress > resumes, call usb_hcd_resume_root_hub. In the issue described in previous email, if we quit suspending, when rh_timer fires the ehci_hub_status_data would be able to go through (instead of returning at the beginning because of hcd->state is suspended) and eventually wakeup the hub_thread to finish resuming the port. >Probably all the host controller drivers will need similar changes. >Does that sound like it will solve your problem? 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
