[Sorry for the delayed response, I was distracted by the btusb regression causing resume to fail on my box.] On Tuesday 10 November 2009, Alan Stern wrote: > On Tue, 10 Nov 2009, Matthew Garrett wrote: > > > On Tue, Nov 10, 2009 at 02:08:01PM +0100, Oliver Neukum wrote: > > > > > I was wondering because a tester has reported a race in ehci that > > > can lead to a loss of wakeup events. Alan posted a patch to fix it. > > > Does it cooperate with your patch? > > > > Hm. I'll look into that. > > There should not be any interaction. That particular race occurs when > the root hub is suspended, not when the controller is suspended. > > > But this does raise an interesting point. We do still have a race > between remote wakeup and system sleep. We do to some extent. There is the check in dpm_prepare() that will abort system sleep transitions if run-time wake-up has been requested earlier, but later requests will be discarded. > Suppose we're in the middle of a system sleep transition, and device D > (such as a USB root hub) has been suspended as part of the normal > preparation. But then D generates a remote wakeup IRQ. > > D's driver will field the interrupt request and will call something > like pm_request_resume(), to schedule a workqueue item for a runtime > resume of D. However, the runtime-PM workqueues are either frozen or > in some other way prevented from doing anything while the system sleep > transition is in progress. > > Therefore the wakeup request will get lost. The information is still > present, in the form of a work_struct, but it won't get acted on until > the system wakes up. In particular, it won't prevent the sleep > transition from completing and it won't cause the system to wake up > immediately after going to sleep. > > This suggests that pm_request_resume() should abort a sleep transition > if one is already in progress. Rafael, what do you think? That's not an easy question, becuase there always will be a point after which we can't handle a run-time resume request. If we are deep enough into the suspend process, we won't receive wakeup interrupts any more, at least on some platforms. Thanks, Rafael -- 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
