On Thu, 20 Aug 2009, Shaohua Li wrote: > > I don't understand the reason behind this. Doesn't this sort of thing > > belong in the bus and platform code, not in the PM core? (In the case > > of UHCI, it should be handled by the platform, in the same way as > > remote wakeup gets enabled before the suspend.) > > > > Drivers don't have to be involved at all. When a wakeup signal is > > detected, the driver's runtime_resume method should get called -- > > nothing more is needed. > The only case is UHCI in my mind. Because UHCI has non-standard wakeup event > register. That's an oversimplification. _Some_ (I think) of _Intel's_ UHCI implementations have a non-standard wakeup event register. > If BIOS doesn't handle it correctly (for example, not clear the wakeup > event after a GPE), we will keep see the wakeup event. And the bus/platform > level has no knowledge to handle such event. How is the wakeup event received? Maybe for this one type of device a PCI quirk will solve the problem. Or if that doesn't work, code can be added to uhci-hcd to turn off the non-standard wakeup register as part of the resume routine. (The problem here is that the resume routine runs in process context so it has to be called after the wakeup event handler has returned.) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
