Re: iwl4965 detection problem

[Jes Sorensen <jes@sgi.com>]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

Jes Sorensen wrote:
> At least it's consistent here as opposed to sometimes.
> 
> One thing I noted is that rmmod often takes a few seconds, no idea
> if it has any value?

Ok,

I think I have an idea at whats going on - loading the module with debug
info revealed that it ended up straight in the interrupt handler the
moment the driver called request_irq(), but obviously before it was
ready to handle the interrupt in question. The net result was that it
didn't get to the loading of the ucode.

Unloading the module meant a call was made to iwl_disable_interrupts()
so on the next load, all pending interrupts in the chip had been cleared
and we didn't see this spurious interrupt.

I haven't had a chance to build the driver with this change, ie. it's
untested, but I have a suspicion that this patch might do the job.

Cheers,
Jes



[-- Attachment #2: iwl4965-irq-fix.diff --]
[-- Type: text/plain, Size: 707 bytes --]

Disable interrupts in the iwl4965 before calling request_irq() for
the case that the previous OS or the BIOS left a pending interrupt in
the chip. This behavior has been observed on some laptops such as T61
Thinkpads and Toshiba Portege R500

Signed-off-by: Jes Sorensen <jes@sgi.com>

--- linux/drivers/net/wireless/iwlwifi/iwl4965-base.c~	2007-10-26 06:49:02.000000000 +0200
+++ linux/drivers/net/wireless/iwlwifi/iwl4965-base.c	2007-10-26 16:03:40.387241088 +0200
@@ -9090,6 +9090,8 @@
 	priv->power_mode = IWL_POWER_AC;
 	priv->user_txpower_limit = IWL_DEFAULT_TX_POWER;
 
+	iwl_disable_interrupts(priv);
+
 	pci_enable_msi(pdev);
 
 	err = request_irq(pdev->irq, iwl_isr, IRQF_SHARED, DRV_NAME, priv);