genirq: reenable a nobody cared disabled irq when a new driver arrives
authorThomas Gleixner <tglx@linutronix.de>
Mon, 28 Apr 2008 15:01:56 +0000 (17:01 +0200)
committerThomas Gleixner <tglx@linutronix.de>
Fri, 2 May 2008 11:40:34 +0000 (13:40 +0200)
commit1adb0850a1254333d81e64121c80af100c6d6e06
tree61835b06e78eb6f556c038ceabc706440f339d3a
parent886c35fbcf6fb2eee15687efc2d64d99b6ad9a4a
genirq: reenable a nobody cared disabled irq when a new driver arrives

Uwe Kleine-Koenig has some strange hardware where one of the shared
interrupts can be asserted during boot before the appropriate driver
loads. Requesting the shared irq line from another driver result in a
spurious interrupt storm which finally disables the interrupt line.

I have seen similar behaviour on resume before (the hardware does not
work anymore so I can not verify).

Change the spurious disable logic to increment the disable depth and
mark the interrupt with an extra flag which allows us to reenable the
interrupt when a new driver arrives which requests the same irq
line. In the worst case this will disable the irq again via the
spurious trap, but there is a decent chance that the new driver is the
one which can handle the already asserted interrupt and makes the box
usable again.

Eric Biederman said further: 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 by a small amount.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-and-Acked-by: Uwe Kleine-K├Ânig <Uwe.Kleine-Koenig@digi.com>
include/linux/irq.h
kernel/irq/manage.c
kernel/irq/spurious.c