Consider two devices A and B sharing an irq and B already asserts the irq on
a booting machine.
If the driver for A is loaded first the irq starts triggering and gets
disabled after some time by note_interrupt().  Later when the driver for B
is loaded the interrupt should be reenabled---other wise both A and B don't
work properly.

Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
 kernel/irq/manage.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 438a014..831ebb2 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -365,11 +365,18 @@ int setup_irq(unsigned int irq, struct irqaction *new)
 
 		desc->status &= ~(IRQ_AUTODETECT | IRQ_WAITING |
 				  IRQ_INPROGRESS);
+	}
+
+	/* in the shared case the interrupt might be disabled if a device
+	 * asserts the irq but the corresponding driver wasn't the first to be
+	 * loaded.  So retry enabling the irq.
+	 */
+	if (!shared || desc->status & IRQ_DISABLED) {
 
 		if (!(desc->status & IRQ_NOAUTOEN)) {
 			desc->depth = 0;
 			desc->status &= ~IRQ_DISABLED;
-			if (desc->chip->startup)
+			if (!shared && desc->chip->startup)
 				desc->chip->startup(irq);
 			else
 				desc->chip->enable(irq);
-- 
1.5.5.1

--

[ message continues ]

On Mon, 28 Apr 2008, Uwe Kleine-K
[ message continues ]

Hello,

mmpf.

It's a ns9215 SoC.  The rtc component has a clock flag that I need to
set before accessing the address space.  After enabling the clock flag
I get an irq if the rtc is up.  The rtc itself uses the same irq.  As I
want to handle the clk enabling in platform code and the actual rtc in a
driver I need a shared irq.
Now the problem is that the rtc remembers its alarm flags over
reboots[1] and starts asserting the irq when the platform code has
requested the irq.

I currently see two ways to handle that:
 1) find an alternative patch similar to the one I sent that don't break
    driver code; or
 2) let the platform code disable the rtc's irqs.

for 1) you need to remember the reason for disabling the irq (or fix all
drivers not to use disable_irq()).  And 2) is ugly because I have to
ioremap then.

Best regards
Uwe

[1] not entirely sure, but I had the rtc in a state in which the rtc
component asserted an irq directly after a reset.

-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962
--

[ message continues ]

On Mon, 28 Apr 2008, Uwe Kleine-K
[ message continues ]

Hello,

Is it intended that IRQ_NO_BALANCING == IRQ_SPURIOUS_DISABLED?

Other than that

Tested-and-Acked-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>

Best regards and thanks
Uwe

-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962
--

[ message continues ]

On Tue, 29 Apr 2008, Uwe Kleine-K
[ message continues ]

Thomas Gleixner <tglx@linutronix.de> writes:

This case also happens on a regular basis in kdump kernels where we
deliberately don't shutdown the hardware before starting the new kernel.
This patch should reduce the need for using irqpoll in that situation

Looks like a duplicate define here. Don't you want:
+#define IRQ_SPURIOUS_DISABLED 0x00800000 /* IRQ was disabled by the spurious trap */
--

[ message continues ]

Your the third one to notice :)

Thanks,
	tglx

--

[ message continues ]