On Tuesday, March 18, 2008 12:32 PM, drago01 wrote: > On Wed, Feb 13, 2008 at 5:48 PM, Chatre, Reinette > <reinette.chatre@xxxxxxxxx> wrote: >> >> On Tuesday, February 12, 2008 11:42 PM, drago01 wrote: >> >> > Tomas Winkler wrote: >> >> On Jan 26, 2008 9:00 PM, drago01 <drago01@xxxxxxxxx> wrote: >> >> >>> On Jan 22, 2008 9:24 PM, drago01 <drago01@xxxxxxxxx> wrote: >>> >> >>>> On Jan 22, 2008 9:21 PM, Winkler, Tomas >> > <tomas.winkler@xxxxxxxxx> wrote: >> >>>> >> >>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: drago01 [mailto:drago01@xxxxxxxxx] >> >>>>>> Sent: Tuesday, January 22, 2008 10:12 PM >> >>>>>> To: Winkler, Tomas >> >>>>>> >> >>>>>> Cc: ipw3945-devel; Cahill, Ben M; Zhu, Yi; linux-wireless >> >>>>>> Subject: Re: [ipw3945-devel] iwl3945 rfkill regression >> >>>>>> >>>>>> On Jan 22, 2008 9:07 PM, Winkler, Tomas >> <tomas.winkler@xxxxxxxxx> >>>>>> >>>>> wrote: >> >>>>> >> >>>>>>> I believe it's delaying uCode load to mac_start - still >> need to >>>>>>> be polished. >>>>>>> >> >>>>>> ok, thx for the quick reply. >> >>>>>> If you have any potential fixes I would be happy to test >> them ;) >>>>>> >>>>> Can you get me the sequence it is happening? >> RF kill switch is off >>>>> before you power up the laptop or >> after, during association or in >>>>> unassociated state..etc Thanks >> >>>>> >> >>>> I boot with rf kill off = device on >> >>>> acciotate using NM >> >>>> kill the card by pressing the rfkill (ie. setting it to on) >> >>>> card is dead (like described in my first mail), until I relaod >> the >>>> module the rfkill switch does not have any effect at this >> time. >>>> >>>> >> >>> OK, I investigated a bit and it seems to be the "disable >> interrupt >>> when device goes down" is the problem. >> >>> In my case NetworkManager detected the rfkill and brought the >> device >>> down, which caused the interrupt to be disabled. Now >> after pressing >>> the rfkill again nothing happend. But if I bring >> the device back up >>> the interrupt is enabled again and rfkill >> and the card is back to >>> live. So in short disabling the >> interrupt in mac_stop breaks the hw >>> rfkill while the interface >> is down. >>> >> >>> >> >> >> >> Thanks for investigating this, still didn't have to time to dig >> into >> it. >> >> >> >> > ping? >> >> We are working on this. >> >> Reinette >> > > OK, it seems not to be the irq (only) seems to be something else too. > I tryed the attached patch (not to disable the irq in down when hw > rfkill is set) but it was still the same. > The driver does not update the sysfs file when the rfkill is back off > (device on), so hal and NM still think that the rfkill is on while > its off. > > Patch (hack) tested: > > diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c > b/drivers/net/wireless/iwlwifi/iwl3945-base.c > index 093b863..70e5e25 100644 > --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c > +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c > @@ -6545,6 +6545,9 @@ static int iwl3945_mac_start(struct > ieee80211_hw *hw) > > IWL_DEBUG_MAC80211("enter\n"); > > + if(!atomic_read(&priv->pci_dev->enable_cnt)) > + goto device_open; > + > if (pci_enable_device(priv->pci_dev)) { > IWL_ERROR("Fail to pci_enable_device\n"); > return -ENODEV; > @@ -6559,6 +6562,7 @@ static int iwl3945_mac_start(struct > ieee80211_hw *hw) goto out_disable_msi; > } > > +device_open: > /* we should be verifying the device is ready to be opened */ > mutex_lock(&priv->mutex); > > @@ -6640,11 +6644,13 @@ static void iwl3945_mac_stop(struct > ieee80211_hw *hw) > > iwl3945_down(priv); > > - flush_workqueue(priv->workqueue); > - free_irq(priv->pci_dev->irq, priv); > - pci_disable_msi(priv->pci_dev); > - pci_save_state(priv->pci_dev); > - pci_disable_device(priv->pci_dev); > + if(!test_bit(STATUS_RF_KILL_HW, &priv->status) && > !test_bit(STATUS_IN_SUSPEND, &priv->status)) { > + flush_workqueue(priv->workqueue); > + free_irq(priv->pci_dev->irq, priv); > + pci_disable_msi(priv->pci_dev); > + pci_save_state(priv->pci_dev); > + pci_disable_device(priv->pci_dev); > + } > > IWL_DEBUG_MAC80211("leave\n"); > } Please note that the driver loads/unloads the firmware during interface up/down. That means that the host will not receive rfkill events while the interface is down as there is no firmware to deal with these events. Reinette -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
