Jouni Malinen wrote:
On Tue, Mar 22, 2005 at 06:11:52PM -0500, Jeff Garzik wrote:
--- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_hw.c
2005-03-12 16:10:40.000000000 -0800
+++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_hw.c 2005-03-12
16:10:58.000000000 -0800
@@ -2790,8 +2790,10 @@
prism2_io_debug_add(dev, PRISM2_IO_DEBUG_CMD_INTERRUPT, 0, 0);
if (local->func->card_present && !local->func->card_present(local)) {
- printk(KERN_DEBUG "%s: Interrupt, but dev not OK\n",
- dev->name);
+ if (net_ratelimit()) {
+ printk(KERN_DEBUG "%s: Interrupt, but dev not OK\n",
+ dev->name);
+ }
return IRQ_HANDLED;
Patch is OK, but it highlights a bug:
You should return IRQ_NONE if the interrupt is not intended for your
hardware.
I'm trying to remember why this was set to IRQ_HANDLED, not IRQ_NONE..
If I remember correctly, every now and then, an interrupt is generated
when removing the PC Card and this ends up getting here. In other words,
the interrupt was actually sort of generated by the hardware device
controlled by the driver. Should this return IRQ_NONE even in that case?
I thought that could end up disabling the IRQ which could also affect
other devices that are sharing the same IRQ.
Well, it should only disable the irq if you get a bunch of interrupts,
not just one or two.
Looking at prism2_interrupt(), there are several cases where you really
want to return IRQ_NONE.
If the hardware is gone, and you get continual interrupts, there's
something wrong (with the cardbus h/w?) that returning IRQ_HANDLED won't
fix.
Jeff
|