On Wed, 11 Nov 2009, Oliver Neukum wrote: > Am Dienstag, 10. November 2009 16:04:12 schrieb Alan Stern: > > 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 seems to be a bit harsh. If you do not specify that a device be > able to wake the whole system, why would it be good for a request > coming from it to abort a system sleep transition? The way you specify that a device be able to wake the whole system is by enabling its remote wakeup attribute. If this attribute is not enabled then the device will not send remote wakeup requests, so the scenario described above will not occur -- no IRQ will be generated. 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
