> 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 ? > (Since the system won't be suspended during a FREEZE, the IRQs should > actually be called resume requests, not wakeup requests. For some devices > there's a difference and for others there isn't. The nomenclature here > has a weak aspect; what the device actually _does_ depends on how the > device is configured, but the _name_ we use depends on what the system is > doing rather than what the device does.) Do we have to actually care ? I guess not in 99% of the cases > One of the main points of FREEZE is to make sure everything is quiet so > that a logically consistent memory image can be prepared for STD. This > can't be done if there are interrupt requests being handled at the same > time. On the other hand, given that interrupts will be disabled while the > memory image is prepared, maybe it doesn't matter if some devices send > wakeup/resume IRQs during FREEZE. It may not matter, indeed... > 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. Ben.
