[PATCH -rt] airo: threaded IRQ handler sleeps forever

[Michal Schmidt <mschmidt@redhat.com>]

The airo driver tries to avoid excessive latencies when issuing commands
to the card by calling schedule() after several retries. But
issuecommand() can be run from an interrupt handler. The function is
careful enough to check with in_atomic() if it is safe to call schedule().
This check breaks when the interrupt handler is threaded, because then
in_atomic() is always false there. The handler is run as
TASK_INTERRUPTIBLE, so schedule() takes it off the runqueue and it never
wakes up again.
Here's an obvious fix - simply don't call schedule() when using
preemptible hardirqs.
An improved solution might be to identify the commands that take so long
to issue and avoid sending them from the interrupt handler. In my
testing there was only one such command: CMD_ACCESS. I need to
investigate if it's always possible to delay it to airo's kthread.

Signed-off-by: Michal Schmidt <mschmidt@redhat.com>

diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index 44a2270..98014c0 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -3938,8 +3938,10 @@ static u16 issuecommand(struct airo_info *ai, Cmd *pCmd, Resp *pRsp) {
 		if ((IN4500(ai, COMMAND)) == pCmd->cmd)
 			// PC4500 didn't notice command, try again
 			OUT4500(ai, COMMAND, pCmd->cmd);
+#ifndef CONFIG_PREEMPT_HARDIRQS
 		if (!in_atomic() && (max_tries & 255) == 0)
 			schedule();
+#endif
 	}
 
 	if ( max_tries == -1 ) {