On Mon, Mar 2, 2009 at 4:08 PM, Arve Hjønnevåg <arve@xxxxxxxxxxx> wrote: > On Mon, Mar 2, 2009 at 3:35 PM, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> >> On Mon, 2 Mar 2009, Linus Torvalds wrote: >>> >>> If IRQ_SUSPENDED _is_ set, then that means that we're after the >>> suspend_late() sequence and before the resume_early() sequence >> >> Sorry, after the suspend, and before the resume. >> >> We could be _in_ the suspend_late/resume_early sequence, but a driver that >> were to try to play with interrupts at that stage would be broken. It >> can't very well do a enable_irq(), because that would be a MAJOR BUG - it >> would make the whole irq suspend thing pointless, since now interrupts >> would start to happen exactly where they must not happen! > > It may be pointless for a driver to call disable_irq and enable_irq > from suspend_late or resume_early (instead of suspend and resume), but > I would not call it a bug. Since disable_irq and enable_irq are > reference counted all this is doing is indicating that this driver can > or cannot accept interrupts. If you want to make an additional > restriction that drivers are not allowed to call disable_irq or > enable_irq from suspend_late and resume_early, then yes you can tell > that enable_irq was called from resume_device_irqs. > > I don't know of any drivers that do this, I was just pointing out the > danger of releasing a reference without knowing if you acquired that > reference. I did think of a driver that can call enable_irq during the suspend_late phase with this patch. This will not cause an extra enable_irq, but it will enable the interrupt since suspend_device_irqs never incremented depth. Our keypad driver disables its interrupt(s) as soon as you press a key and starts a timer to scan the keypad. When the timer detects that no keys are pressed, it re-enables the interrupt. Since timers now run during suspend_late, this enable_irq call can happen after suspend_device_irqs. If suspend_device_irqs increments depth even if it is not zero, this can be avoided. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
