Hi,
Hi recent updates to wireless-2.6 / iwlwifi (1.2.22->1.2.23) broke
rfkill in a weird way for me.
What happens:
When I switch off the card using the hw rfkill switch (while
acciotated) I get this in dmesg:
iwl3945: Radio Frequency Kill Switch is On:
Kill switch must be turned off for wireless networking to work.
wlan0: disassociate(reason=3)
wlan0: disassociate(reason=3)
iwl3945: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl3945: MAC is in deep sleep!
iwl3945: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl3945: MAC is in deep sleep!
iwl3945: WARNING: Requesting MAC access during RFKILL wakes up NIC
iwl3945: MAC is in deep sleep!
iwl3945: WARNING: Requesting MAC access during RFKILL wakes up NIC
ACPI: PCI interrupt for device 0000:07:00.0 disabled
Notice the last line (interupt gets disabled). When this happens there
is no way to get the card back up other then reloading the module.
Earlier version (1.2.22) was working fine I could switch the switch
on/off without having an suchs kind of issues.
I have not tryed to find out which patch broke it yet, but I suspect
the suspend / resume rfkill fix mighr be the culprit.
If any more tests / information is needed feel free to ask.
>-----Original Message-----
>From: [email protected]
[mailto:ipw3945-devel-
>[email protected]] On Behalf Of drago01
>Sent: Tuesday, January 22, 2008 10:05 PM
>To: ipw3945-devel
>Cc: Cahill, Ben M; Zhu, Yi; linux-wireless
>Subject: [ipw3945-devel] iwl3945 rfkill regression
>
>Hi,
>Hi recent updates to wireless-2.6 / iwlwifi (1.2.22->1.2.23) broke
>rfkill in a weird way for me.
>What happens:
>When I switch off the card using the hw rfkill switch (while
>acciotated) I get this in dmesg:
>iwl3945: Radio Frequency Kill Switch is On:
>Kill switch must be turned off for wireless networking to work.
>wlan0: disassociate(reason=3)
>wlan0: disassociate(reason=3)
>iwl3945: WARNING: Requesting MAC access during RFKILL wakes up NIC
>iwl3945: MAC is in deep sleep!
>iwl3945: WARNING: Requesting MAC access during RFKILL wakes up NIC
>iwl3945: MAC is in deep sleep!
>iwl3945: WARNING: Requesting MAC access during RFKILL wakes up NIC
>iwl3945: MAC is in deep sleep!
>iwl3945: WARNING: Requesting MAC access during RFKILL wakes up NIC
>ACPI: PCI interrupt for device 0000:07:00.0 disabled
>
>Notice the last line (interupt gets disabled). When this happens there
>is no way to get the card back up other then reloading the module.
>Earlier version (1.2.22) was working fine I could switch the switch
>on/off without having an suchs kind of issues.
>I have not tryed to find out which patch broke it yet, but I suspect
>the suspend / resume rfkill fix mighr be the culprit.
>
>If any more tests / information is needed feel free to ask.
>
I believe it's delaying uCode load to mac_start - still need to be
polished.
Tomas
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
On Jan 22, 2008 9:24 PM, drago01 <[email protected]> wrote:
> On Jan 22, 2008 9:21 PM, Winkler, Tomas <[email protected]> wrote:
> >
> >
> > >-----Original Message-----
> > >From: drago01 [mailto:[email protected]]
> > >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 <[email protected]>
> > 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.
>-----Original Message-----
>From: drago01 [mailto:[email protected]]
>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 <[email protected]>
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
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
On Jan 26, 2008 9:00 PM, drago01 <[email protected]> wrote:
> On Jan 22, 2008 9:24 PM, drago01 <[email protected]> wrote:
> > On Jan 22, 2008 9:21 PM, Winkler, Tomas <[email protected]> wrote:
> > >
> > >
> > > >-----Original Message-----
> > > >From: drago01 [mailto:[email protected]]
> > > >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 <[email protected]>
> > > 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.
Tomas
On Jan 22, 2008 9:07 PM, Winkler, Tomas <[email protected]> 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 ;)
On Jan 22, 2008 9:29 PM, Winkler, Tomas <[email protected]> wrote:
>
>
> >-----Original Message-----
> >From: drago01 [mailto:[email protected]]
>
> >Sent: Tuesday, January 22, 2008 10:24 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:21 PM, Winkler, Tomas <[email protected]>
> wrote:
> >>
> >>
> >> >-----Original Message-----
> >> >From: drago01 [mailto:[email protected]]
> >> >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 <[email protected]>
> >> 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.
>
> Okay thanks, I'll try to look at it tomorrow
> Tomas
OK, thx
On Jan 22, 2008 9:21 PM, Winkler, Tomas <[email protected]> wrote:
>
>
> >-----Original Message-----
> >From: drago01 [mailto:[email protected]]
> >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 <[email protected]>
> 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.
>-----Original Message-----
>From: drago01 [mailto:[email protected]]
>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 <[email protected]>
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 ;)
Unfortunately not this time.
Tomas
>-----Original Message-----
>From: drago01 [mailto:[email protected]]
>Sent: Tuesday, January 22, 2008 10:24 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:21 PM, Winkler, Tomas <[email protected]>
wrote:
>>
>>
>> >-----Original Message-----
>> >From: drago01 [mailto:[email protected]]
>> >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 <[email protected]>
>> 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.
Okay thanks, I'll try to look at it tomorrow
Tomas
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
On Jan 22, 2008 9:29 PM, Winkler, Tomas <[email protected]> wrote:
>
>
> >-----Original Message-----
> >From: drago01 [mailto:[email protected]]
>
> >Sent: Tuesday, January 22, 2008 10:24 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:21 PM, Winkler, Tomas <[email protected]>
> wrote:
> >>
> >>
> >> >-----Original Message-----
> >> >From: drago01 [mailto:[email protected]]
> >> >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 <[email protected]>
> >> 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.
>
> Okay thanks, I'll try to look at it tomorrow
Any updates? Can this patch be reerted until the regressions are sorted out?
Tomas Winkler wrote:
> On Jan 26, 2008 9:00 PM, drago01 <[email protected]> wrote:
>
>> On Jan 22, 2008 9:24 PM, drago01 <[email protected]> wrote:
>>
>>> On Jan 22, 2008 9:21 PM, Winkler, Tomas <[email protected]> wrote:
>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: drago01 [mailto:[email protected]]
>>>>> 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 <[email protected]>
>>>>>
>>>> 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?
On Tuesday, February 12, 2008 11:42 PM, drago01 wrote:
> Tomas Winkler wrote:
>> On Jan 26, 2008 9:00 PM, drago01 <[email protected]> wrote:
>>
>>> On Jan 22, 2008 9:24 PM, drago01 <[email protected]> wrote:
>>>
>>>> On Jan 22, 2008 9:21 PM, Winkler, Tomas
> <[email protected]> wrote:
>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: drago01 [mailto:[email protected]]
>>>>>> 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 <[email protected]>
>>>>>>
>>>>> 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
> 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
>
OK that makes sense.
So a solution would be to not unload the firmware on down when the hw
rfkill is on. Is this a acceptable one or are they other (better
solutions).
I can't think of any. And userspace cannot do anything because
bringing the device up and down again to look for the rfkill status
would be racy.
On Wed, Mar 19, 2008 at 12:35 AM, Tomas Winkler <[email protected]> wrote:
>
> On Wed, Mar 19, 2008 at 1:10 AM, drago01 <[email protected]> wrote:
> >
> > On Wed, Mar 19, 2008 at 12:07 AM, Tomas Winkler <[email protected]> wrote:
> > > On Wed, Mar 19, 2008 at 12:06 AM, Chatre, Reinette
> > >
> > > <[email protected]> wrote:
> > > >
> > >
> > >
> > > > On Tuesday, March 18, 2008 2:47 PM, drago01 wrote:
> > > >
> > > > >> 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
> > > > >>
> > > > >
> > > > > OK that makes sense.
> > > > > So a solution would be to not unload the firmware on down when the hw
> > > > > rfkill is on. Is this a acceptable one or are they other (better
> > > > > solutions). I can't think of any. And userspace cannot do anything
> > > > > because bringing the device up and down again to look for the rfkill
> > > > > status would be racy.
> > > >
> > > > Having the firmware unloaded when the interface is down is a requirement
> > > > for powersaving. We do not want the device to consume power when it is
> > > > not used. The rfkill status should always be reported accurately when
> > > > the interface is up. If it is not then it is a bug.
> > >
> > > We will catch the HW rfkill event after loading the uCode so there is
> > > no problem with this.
> > > Not sure where should be the SW rfkill state stored.
> >
> > yeah, but the ucode will be loaded when the device is brought back up,
> > which does not happen in NM's case.
> >
>
> You mean that NM doesn't have any notification that the radio was enabled again?
yes
> This one is tricky with 3945...the trivial question is why NM disables
> the device?
Thats a question for Dan, maybe other devices/drivers just send an
event to userspace "please disable the radio" ?
> In 4965 there is an interrupt announcing rkfil, in 3965 it's event
> from firmware. There was portably a good reason why the interrupt was
> added :)
OK, but aren't the interrupts disabled too on down? (don't have any
4965 hw to test with)
> Sorry no solution for now.
ok, might be a way to solve it in userspace (not bringing down the device)
On Tuesday, March 18, 2008 12:32 PM, drago01 wrote:
> On Wed, Feb 13, 2008 at 5:48 PM, Chatre, Reinette
> <[email protected]> wrote:
>>
>> On Tuesday, February 12, 2008 11:42 PM, drago01 wrote:
>>
>> > Tomas Winkler wrote:
>> >> On Jan 26, 2008 9:00 PM, drago01 <[email protected]> wrote: >>
>> >>> On Jan 22, 2008 9:24 PM, drago01 <[email protected]> wrote: >>>
>> >>>> On Jan 22, 2008 9:21 PM, Winkler, Tomas
>> > <[email protected]> wrote:
>> >>>>
>> >>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> From: drago01 [mailto:[email protected]]
>> >>>>>> 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
>> <[email protected]> >>>>>> >>>>> 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
On Wed, Mar 19, 2008 at 1:10 AM, drago01 <[email protected]> wrote:
>
> On Wed, Mar 19, 2008 at 12:07 AM, Tomas Winkler <[email protected]> wrote:
> > On Wed, Mar 19, 2008 at 12:06 AM, Chatre, Reinette
> >
> > <[email protected]> wrote:
> > >
> >
> >
> > > On Tuesday, March 18, 2008 2:47 PM, drago01 wrote:
> > >
> > > >> 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
> > > >>
> > > >
> > > > OK that makes sense.
> > > > So a solution would be to not unload the firmware on down when the hw
> > > > rfkill is on. Is this a acceptable one or are they other (better
> > > > solutions). I can't think of any. And userspace cannot do anything
> > > > because bringing the device up and down again to look for the rfkill
> > > > status would be racy.
> > >
> > > Having the firmware unloaded when the interface is down is a requirement
> > > for powersaving. We do not want the device to consume power when it is
> > > not used. The rfkill status should always be reported accurately when
> > > the interface is up. If it is not then it is a bug.
> >
> > We will catch the HW rfkill event after loading the uCode so there is
> > no problem with this.
> > Not sure where should be the SW rfkill state stored.
>
> yeah, but the ucode will be loaded when the device is brought back up,
> which does not happen in NM's case.
>
You mean that NM doesn't have any notification that the radio was enabled again?
This one is tricky with 3945...the trivial question is why NM disables
the device?
In 4965 there is an interrupt announcing rkfil, in 3965 it's event
from firmware. There was portably a good reason why the interrupt was
added :)
Sorry no solution for now.
Tomas
On Tuesday, March 18, 2008 2:47 PM, drago01 wrote:
>> 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
>>
>
> OK that makes sense.
> So a solution would be to not unload the firmware on down when the hw
> rfkill is on. Is this a acceptable one or are they other (better
> solutions). I can't think of any. And userspace cannot do anything
> because bringing the device up and down again to look for the rfkill
> status would be racy.
Having the firmware unloaded when the interface is down is a requirement
for powersaving. We do not want the device to consume power when it is
not used. The rfkill status should always be reported accurately when
the interface is up. If it is not then it is a bug.
Reinette
On Wed, Mar 19, 2008 at 1:40 AM, drago01 <[email protected]> wrote:
>
> On Wed, Mar 19, 2008 at 12:35 AM, Tomas Winkler <[email protected]> wrote:
> >
> > On Wed, Mar 19, 2008 at 1:10 AM, drago01 <[email protected]> wrote:
> > >
> > > On Wed, Mar 19, 2008 at 12:07 AM, Tomas Winkler <[email protected]> wrote:
> > > > On Wed, Mar 19, 2008 at 12:06 AM, Chatre, Reinette
> > > >
> > > > <[email protected]> wrote:
> > > > >
> > > >
> > > >
> > > > > On Tuesday, March 18, 2008 2:47 PM, drago01 wrote:
> > > > >
> > > > > >> 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
> > > > > >>
> > > > > >
> > > > > > OK that makes sense.
> > > > > > So a solution would be to not unload the firmware on down when the hw
> > > > > > rfkill is on. Is this a acceptable one or are they other (better
> > > > > > solutions). I can't think of any. And userspace cannot do anything
> > > > > > because bringing the device up and down again to look for the rfkill
> > > > > > status would be racy.
> > > > >
> > > > > Having the firmware unloaded when the interface is down is a requirement
> > > > > for powersaving. We do not want the device to consume power when it is
> > > > > not used. The rfkill status should always be reported accurately when
> > > > > the interface is up. If it is not then it is a bug.
> > > >
> > > > We will catch the HW rfkill event after loading the uCode so there is
> > > > no problem with this.
> > > > Not sure where should be the SW rfkill state stored.
> > >
> > > yeah, but the ucode will be loaded when the device is brought back up,
> > > which does not happen in NM's case.
> > >
> >
> > You mean that NM doesn't have any notification that the radio was enabled again?
> yes
>
>
> > This one is tricky with 3945...the trivial question is why NM disables
> > the device?
> Thats a question for Dan, maybe other devices/drivers just send an
> event to userspace "please disable the radio" ?
>
>
> > In 4965 there is an interrupt announcing rkfil, in 3965 it's event
> > from firmware. There was portably a good reason why the interrupt was
> > added :)
>
> OK, but aren't the interrupts disabled too on down? (don't have any
> 4965 hw to test with)
Should not be.
>
> > Sorry no solution for now.
>
> ok, might be a way to solve it in userspace (not bringing down the device)
That will probably work.. still need more investigation.
On Wed, 2008-03-19 at 01:35 +0200, Tomas Winkler wrote:
> On Wed, Mar 19, 2008 at 1:10 AM, drago01 <[email protected]> wrote:
> >
> > On Wed, Mar 19, 2008 at 12:07 AM, Tomas Winkler <[email protected]> wrote:
> > > On Wed, Mar 19, 2008 at 12:06 AM, Chatre, Reinette
> > >
> > > <[email protected]> wrote:
> > > >
> > >
> > >
> > > > On Tuesday, March 18, 2008 2:47 PM, drago01 wrote:
> > > >
> > > > >> 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
> > > > >>
> > > > >
> > > > > OK that makes sense.
> > > > > So a solution would be to not unload the firmware on down when the hw
> > > > > rfkill is on. Is this a acceptable one or are they other (better
> > > > > solutions). I can't think of any. And userspace cannot do anything
> > > > > because bringing the device up and down again to look for the rfkill
> > > > > status would be racy.
> > > >
> > > > Having the firmware unloaded when the interface is down is a requirement
> > > > for powersaving. We do not want the device to consume power when it is
> > > > not used. The rfkill status should always be reported accurately when
> > > > the interface is up. If it is not then it is a bug.
> > >
> > > We will catch the HW rfkill event after loading the uCode so there is
> > > no problem with this.
> > > Not sure where should be the SW rfkill state stored.
> >
> > yeah, but the ucode will be loaded when the device is brought back up,
> > which does not happen in NM's case.
> >
>
> You mean that NM doesn't have any notification that the radio was enabled again?
Well, NM would only be able to get that notification via HAL, which
would get the notification via the kernel RFKill layer or the input
layer. In the case of iwlwifi, that even must come through the kernel
rfkill layer, however the driver decides to post that event.
> This one is tricky with 3945...the trivial question is why NM disables
> the device?
Because when the device is down (!IFF_UP), then the device is supposed
to enter the deepest power saving mode that it supports. That's the
same for ethernet drivers and wireless drivers. I think it's pretty
much up to the driver/ucode to track rfkill state across up/down/etc.
If 3945 can only detect the rfkill change when the ucode is loaded, then
we have a problem.
I'm not opposed to changing NetworkManager to keep the device up, but
just setting the TX power to 'off', though we must keep in mind that the
device is (a) not in a lowest power mode because RX circuits can still
be on, and (b) not all drivers probably respect WEXT txpower. I don't
care about (b) at all, those drivers just have to get fixed. But (a)
worries me since we don't have any API for inactive power saving modes
right now _other_ than !IFF_UP. We will drain more power than setting
the device !IFF_UP.
Dan
> In 4965 there is an interrupt announcing rkfil, in 3965 it's event
> from firmware. There was portably a good reason why the interrupt was
> added :)
>
> Sorry no solution for now.
>
> Tomas
On Wed, Feb 13, 2008 at 5:48 PM, Chatre, Reinette
<[email protected]> wrote:
>
> On Tuesday, February 12, 2008 11:42 PM, drago01 wrote:
>
> > Tomas Winkler wrote:
> >> On Jan 26, 2008 9:00 PM, drago01 <[email protected]> wrote:
> >>
> >>> On Jan 22, 2008 9:24 PM, drago01 <[email protected]> wrote:
> >>>
> >>>> On Jan 22, 2008 9:21 PM, Winkler, Tomas
> > <[email protected]> wrote:
> >>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: drago01 [mailto:[email protected]]
> >>>>>> 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 <[email protected]>
> >>>>>>
> >>>>> 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");
}
On Wed, Mar 19, 2008 at 12:06 AM, Chatre, Reinette
<[email protected]> wrote:
>
> On Tuesday, March 18, 2008 2:47 PM, drago01 wrote:
>
> >> 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
> >>
> >
> > OK that makes sense.
> > So a solution would be to not unload the firmware on down when the hw
> > rfkill is on. Is this a acceptable one or are they other (better
> > solutions). I can't think of any. And userspace cannot do anything
> > because bringing the device up and down again to look for the rfkill
> > status would be racy.
>
> Having the firmware unloaded when the interface is down is a requirement
> for powersaving. We do not want the device to consume power when it is
> not used. The rfkill status should always be reported accurately when
> the interface is up. If it is not then it is a bug.
We will catch the HW rfkill event after loading the uCode so there is
no problem with this.
Not sure where should be the SW rfkill state stored.
> Reinette
>
On Wed, Mar 19, 2008 at 12:07 AM, Tomas Winkler <[email protected]> wrote:
> On Wed, Mar 19, 2008 at 12:06 AM, Chatre, Reinette
>
> <[email protected]> wrote:
> >
>
>
> > On Tuesday, March 18, 2008 2:47 PM, drago01 wrote:
> >
> > >> 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
> > >>
> > >
> > > OK that makes sense.
> > > So a solution would be to not unload the firmware on down when the hw
> > > rfkill is on. Is this a acceptable one or are they other (better
> > > solutions). I can't think of any. And userspace cannot do anything
> > > because bringing the device up and down again to look for the rfkill
> > > status would be racy.
> >
> > Having the firmware unloaded when the interface is down is a requirement
> > for powersaving. We do not want the device to consume power when it is
> > not used. The rfkill status should always be reported accurately when
> > the interface is up. If it is not then it is a bug.
>
> We will catch the HW rfkill event after loading the uCode so there is
> no problem with this.
> Not sure where should be the SW rfkill state stored.
yeah, but the ucode will be loaded when the device is brought back up,
which does not happen in NM's case.
On Wed, 2008-03-19 at 10:15 -0400, Dan Williams wrote:
> On Wed, 2008-03-19 at 01:35 +0200, Tomas Winkler wrote:
> > On Wed, Mar 19, 2008 at 1:10 AM, drago01 <[email protected]> wrote:
> > >
> > > On Wed, Mar 19, 2008 at 12:07 AM, Tomas Winkler <[email protected]> wrote:
> > > > On Wed, Mar 19, 2008 at 12:06 AM, Chatre, Reinette
> > > >
> > > > <[email protected]> wrote:
> > > > >
> > > >
> > > >
> > > > > On Tuesday, March 18, 2008 2:47 PM, drago01 wrote:
> > > > >
> > > > > >> 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
> > > > > >>
> > > > > >
> > > > > > OK that makes sense.
> > > > > > So a solution would be to not unload the firmware on down when the hw
> > > > > > rfkill is on. Is this a acceptable one or are they other (better
> > > > > > solutions). I can't think of any. And userspace cannot do anything
> > > > > > because bringing the device up and down again to look for the rfkill
> > > > > > status would be racy.
> > > > >
> > > > > Having the firmware unloaded when the interface is down is a requirement
> > > > > for powersaving. We do not want the device to consume power when it is
> > > > > not used. The rfkill status should always be reported accurately when
> > > > > the interface is up. If it is not then it is a bug.
> > > >
> > > > We will catch the HW rfkill event after loading the uCode so there is
> > > > no problem with this.
> > > > Not sure where should be the SW rfkill state stored.
> > >
> > > yeah, but the ucode will be loaded when the device is brought back up,
> > > which does not happen in NM's case.
> > >
> >
> > You mean that NM doesn't have any notification that the radio was enabled again?
>
> Well, NM would only be able to get that notification via HAL, which
> would get the notification via the kernel RFKill layer or the input
> layer. In the case of iwlwifi, that even must come through the kernel
> rfkill layer, however the driver decides to post that event.
>
> > This one is tricky with 3945...the trivial question is why NM disables
> > the device?
>
> Because when the device is down (!IFF_UP), then the device is supposed
> to enter the deepest power saving mode that it supports. That's the
> same for ethernet drivers and wireless drivers. I think it's pretty
> much up to the driver/ucode to track rfkill state across up/down/etc.
>
> If 3945 can only detect the rfkill change when the ucode is loaded, then
> we have a problem.
>
> I'm not opposed to changing NetworkManager to keep the device up, but
> just setting the TX power to 'off', though we must keep in mind that the
> device is (a) not in a lowest power mode because RX circuits can still
> be on, and (b) not all drivers probably respect WEXT txpower. I don't
> care about (b) at all, those drivers just have to get fixed. But (a)
> worries me since we don't have any API for inactive power saving modes
> right now _other_ than !IFF_UP. We will drain more power than setting
> the device !IFF_UP.
So I did this, but we need a few changes to HAL, because the rfkill bits
there aren't rich enough to distinguish between a hardware rfkill and a
software rfkill. So when SIOCSIWTXPOW to 'off', all you can get out of
HAL is "I'm dead", which doesn't let you know whether you can turn the
radio back on with SIOCSIWTXPOW or whether there's a switch flipped
somewhere.
Dan
> Dan
>
> > In 4965 there is an interrupt announcing rkfil, in 3965 it's event
> > from firmware. There was portably a good reason why the interrupt was
> > added :)
> >
> > Sorry no solution for now.
> >
> > Tomas
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2008-04-23 at 15:26 -0400, Dan Williams wrote:
> On Wed, 2008-03-19 at 10:15 -0400, Dan Williams wrote:
> > On Wed, 2008-03-19 at 01:35 +0200, Tomas Winkler wrote:
> > > On Wed, Mar 19, 2008 at 1:10 AM, drago01 <[email protected]> wrote:
> > > >
> > > > On Wed, Mar 19, 2008 at 12:07 AM, Tomas Winkler <[email protected]> wrote:
> > > > > On Wed, Mar 19, 2008 at 12:06 AM, Chatre, Reinette
> > > > >
> > > > > <[email protected]> wrote:
> > > > > >
> > > > >
> > > > >
> > > > > > On Tuesday, March 18, 2008 2:47 PM, drago01 wrote:
> > > > > >
> > > > > > >> 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
> > > > > > >>
> > > > > > >
> > > > > > > OK that makes sense.
> > > > > > > So a solution would be to not unload the firmware on down when the hw
> > > > > > > rfkill is on. Is this a acceptable one or are they other (better
> > > > > > > solutions). I can't think of any. And userspace cannot do anything
> > > > > > > because bringing the device up and down again to look for the rfkill
> > > > > > > status would be racy.
> > > > > >
> > > > > > Having the firmware unloaded when the interface is down is a requirement
> > > > > > for powersaving. We do not want the device to consume power when it is
> > > > > > not used. The rfkill status should always be reported accurately when
> > > > > > the interface is up. If it is not then it is a bug.
> > > > >
> > > > > We will catch the HW rfkill event after loading the uCode so there is
> > > > > no problem with this.
> > > > > Not sure where should be the SW rfkill state stored.
> > > >
> > > > yeah, but the ucode will be loaded when the device is brought back up,
> > > > which does not happen in NM's case.
> > > >
> > >
> > > You mean that NM doesn't have any notification that the radio was enabled again?
> >
> > Well, NM would only be able to get that notification via HAL, which
> > would get the notification via the kernel RFKill layer or the input
> > layer. In the case of iwlwifi, that even must come through the kernel
> > rfkill layer, however the driver decides to post that event.
> >
> > > This one is tricky with 3945...the trivial question is why NM disables
> > > the device?
> >
> > Because when the device is down (!IFF_UP), then the device is supposed
> > to enter the deepest power saving mode that it supports. That's the
> > same for ethernet drivers and wireless drivers. I think it's pretty
> > much up to the driver/ucode to track rfkill state across up/down/etc.
> >
> > If 3945 can only detect the rfkill change when the ucode is loaded, then
> > we have a problem.
> >
> > I'm not opposed to changing NetworkManager to keep the device up, but
> > just setting the TX power to 'off', though we must keep in mind that the
> > device is (a) not in a lowest power mode because RX circuits can still
> > be on, and (b) not all drivers probably respect WEXT txpower. I don't
> > care about (b) at all, those drivers just have to get fixed. But (a)
> > worries me since we don't have any API for inactive power saving modes
> > right now _other_ than !IFF_UP. We will drain more power than setting
> > the device !IFF_UP.
>
> So I did this, but we need a few changes to HAL, because the rfkill bits
> there aren't rich enough to distinguish between a hardware rfkill and a
> software rfkill. So when SIOCSIWTXPOW to 'off', all you can get out of
> HAL is "I'm dead", which doesn't let you know whether you can turn the
Clarification: this behavior was seen on ipw2200. Drivers/hardware that
use the kernels' rfkill framework may be different.
Dan
> radio back on with SIOCSIWTXPOW or whether there's a switch flipped
> somewhere.
>
> Dan
>
> > Dan
> >
> > > In 4965 there is an interrupt announcing rkfil, in 3965 it's event
> > > from firmware. There was portably a good reason why the interrupt was
> > > added :)
> > >
> > > Sorry no solution for now.
> > >
> > > Tomas
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html