[PATCH] powerpc: EOI spurious irqs during boot so they can be reenabled later

In the xics code, if we receive an irq during boot that hasn't been setup
yet - ie. we have no reverse mapping for it - we mask the irq so we don't
hear from it again.

Later on if someone request_irq()'s that irq, we'll unmask it but it will
still never fire. This is because we never EOI'ed the irq when we originally
received it - when it was spurious.

This can be reproduced trivially by banging the keyboard while kexec'ing on
a P5 LPAR, even though the hvc_console driver request's the console irq later
in boot, the console is non-functional because we're receiving no console
interrupts.

So when we receive a spurious irq, EOI it, and then mask it.

Signed-off-by: Michael Ellerman <redacted>
---
 arch/powerpc/platforms/pseries/xics.c |   29 ++++++++++++++++++++---------
 1 files changed, 20 insertions(+), 9 deletions(-)


Probably 27 material unless there are objections ..

diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
index 0fc830f..dc007f4 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c

@@ -321,21 +321,26 @@ static unsigned int xics_startup(unsigned int virq)
 	return 0;
 }
 
+static void xics_eoi_hwirq_direct(unsigned int hwirq)
+{
+	iosync();
+	direct_xirr_info_set((0xff << 24) | hwirq);
+}
+
 static void xics_eoi_direct(unsigned int virq)
 {
-	unsigned int irq = (unsigned int)irq_map[virq].hwirq;
+	xics_eoi_hwirq_direct((unsigned int)irq_map[virq].hwirq);
+}
 
+static void xics_eoi_hwirq_lpar(unsigned int hwirq)
+{
 	iosync();
-	direct_xirr_info_set((0xff << 24) | irq);
+	lpar_xirr_info_set((0xff << 24) | hwirq);
 }
 
-
 static void xics_eoi_lpar(unsigned int virq)
 {
-	unsigned int irq = (unsigned int)irq_map[virq].hwirq;
-
-	iosync();
-	lpar_xirr_info_set((0xff << 24) | irq);
+	xics_eoi_hwirq_lpar((unsigned int)irq_map[virq].hwirq);
 }
 
 static inline unsigned int xics_remap_irq(unsigned int vec)

@@ -350,9 +355,15 @@ static inline unsigned int xics_remap_irq(unsigned int vec)
 	if (likely(irq != NO_IRQ))
 		return irq;
 
-	printk(KERN_ERR "Interrupt %u (real) is invalid,"
-	       " disabling it.\n", vec);
+	pr_err("%s: no mapping for hwirq %u, disabling it.\n", __func__, vec);
+
+	if (firmware_has_feature(FW_FEATURE_LPAR))
+		xics_eoi_hwirq_lpar(vec);
+	else
+		xics_eoi_hwirq_direct(vec);
+
 	xics_mask_real_irq(vec);
+
 	return NO_IRQ;
 }
 

-- 
1.5.5

So when we receive a spurious irq, EOI it, and then mask it.

What happens when a new IRQ arrives on the interrupt controller
between these EOI and mask calls?  Should you instead first mask
it, and only then EOI it?  Or doesn't that work on XICS?


Segher

On Tue, 2008-08-05 at 18:48 +0200, Segher Boessenkool wrote:

quoted

So when we receive a spurious irq, EOI it, and then mask it.

What happens when a new IRQ arrives on the interrupt controller
between these EOI and mask calls?  Should you instead first mask
it, and only then EOI it?  Or doesn't that work on XICS?

Yeah right, in which case we'd have not EOI'ed that one and we're back
at square one.

It seems to work with a mask then EOI, so unless Milton says otherwise
I'll do it that way - new patch coming.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person