On Mon, Jul 22, 2013 at 11:49:34AM -0400, Konrad Rzeszutek Wilk wrote:On Fri, Jul 19, 2013 at 05:29:16PM +0200, Thomas Gleixner wrote:It is good. You can add an Acked-by-and-Tested-by from me if you wouldOn Tue, 9 Jul 2013, Laxman Dewangan wrote:It should not. I did test it and it ran just fine throught theWhen system enters into suspend, it disable all irqs in single
function call. This disables EARLY_RESUME irqs also along with
normal irqs.
The EARLY_RESUME irqs get enabled in sys_core_ops->resume and
non-EARLY_RESUME irqs get enabled in normal system resume path.
When suspend_noirq failed or suspend is aborted for any reason,
the EARLY_RESUME irqs do not get enabled as sys_core_ops->resume()
call did not happen. It only enables the non-EARLY_RESUME irqs in normal
disable for remaining life of system.
Add checks on normal irq_resume() whether EARLY_RESUME irqs have been
enabled or not and if not then enable it forcefully.
+static bool early_resume_irq_suspended;Instead of doing that status dance, we could simply reenable all
+
interrupts in irq_resume(). There's nothing wrong to unmask the few
IRQF_EARLY_RESUME interrupts again.
Just the XEN ones might be upset. Konrad ?
gauntlet test - but let me check it with me looking at the console.
like. Thanks!
Thanks,
tglx
Index: linux-2.6/kernel/irq/pm.c
===================================================================
--- linux-2.6.orig/kernel/irq/pm.c
+++ linux-2.6/kernel/irq/pm.c
@@ -50,7 +50,7 @@ static void resume_irqs(bool want_early)
bool is_early = desc->action &&
desc->action->flags & IRQF_EARLY_RESUME;
- if (is_early != want_early)
+ if (!is_early && want_early)
continue;
raw_spin_lock_irqsave(&desc->lock, flags);