On Thu, 4 Nov 2004, Benjamin Herrenschmidt wrote: > > > Right, they're only _needed_ for STANDBY and SUSPEND. But are > > wakeup/resume IRQs _legal_ for FREEZE? > > If your system is ready to cope with them... I don't know what happens > in the world of ACPI there. On PPC, those aren't IRQs per-se but > separate signals going to the power management unit uC which will simply > ignore them when the machine is not suspended. > > What should we set as a policy there ? I don't know, but there is a potential problem about wakeup IRQs getting lost. While it might not affect PPC, it would affect other architectures. See below. > > In short, should devices be allowed to send wakeup/resume IRQs during > > FREEZE? > > > > Pro: Yes, because they are allowed to do so during SUSPEND > > and FREEZE should be less restrictive than SUSPEND. > > > > Con: No, because a frozen device shouldn't do anything that > > would disturb the system, including sending an IRQ. > > The above (Con) is also true for SUSPENDED devices, so there's a kind of > paradox here... On the other hand, what is the usual action of a driver > upon reception of such an irq ? I's say most of the time, nothing but > ack'ing it on the HW no ? That won't really affect any state. > > I don't know what to set as a policy here. Depending on exactly how STD is implemented, there may be a window following the creation of the memory image during which interrupts are enabled (like while the image is being written to swap) and a wakeup-enabled device gets a wakeup event. If the device does send a wakeup/resume signal and the IRQ is acknowledged, then bad things could happen. Any change in the driver's memory records wouldn't be in the stored image. At the very least we could expect that the wakeup request would be turned off by the interrupt handler, so that it would not hang around to cause an immediate wakeup when the actual suspend starts. Furthermore it's quite likely that the driver wouldn't be able to re-enable remote wakeup on the device, so that even if another wakeup event arrived later the device couldn't wake up the system. I'm not sure what the best way is to handle this. It's fairly unlikely, so we could just ignore it for now. Ultimately it may be necessary to say that wakeup/resume IRQs must _not_ be enabled during FREEZE, and they must remain disabled until a final suspend (or power off) message is broadcast with interrupts disabled. This strikes me as very awkward and possibly not feasible, but I can't think of anything better at the moment. Alan Stern
