Re: [PATCH wireless-2.6 7/10] hostap: Rate limiting for debug messages

[Jeff Garzik <jgarzik@pobox.com>]

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