Hi,
Since the patch "iwlwifi: delay firmware loading from pci_probe to network
interface open" was merged, the driver's killswitch does not work anymore
when the interface is down. The patch comment contains two arguments for
that behaviour:
1) ... Because kernel initializes network devices subsystem before hard disk
and SATA subsystem, it is impossible to get the firmware image from hard disk
in the PCI probe handler. ...
2) For better power saving ...
The current driver behavior is as follows:
- iwl_pci_probe initializes the driver but disables the device, at this point
changing the killswitch state will not be noticed by the driver and thus
the killswitch state in sysfs will not reflect the real state
- iwl_mac_start (which is called when at least one interface goes up) starts
the device and loads the firmware if the killswitch is disabled. Otherwise
the driver will just enable the interrupts and allows the interface to go
up.
However, if the device fires the interrupt CSR_INT_BIT_RF_KILL the code in
iwl_irq_tasklet will _not_ restart the card, although the driver already
allowed the interface to go up. That should easily be fixable with a patch
similar to the following (the comment should be changed too):
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index b935e9d..e2f160b 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -1504,8 +1504,11 @@ static void iwl_irq_tasklet(struct iwl_priv *priv)
* the driver as well won't allow loading if RFKILL is set
* therefore no need to restart the driver from this handler
*/
- if (!hw_rf_kill && !test_bit(STATUS_ALIVE, &priv->status))
+ if (!hw_rf_kill && !test_bit(STATUS_ALIVE, &priv->status)) {
clear_bit(STATUS_RF_KILL_HW, &priv->status);
+ if (priv->is_open)
+ queue_work(priv->workqueue, &priv->restart);
+ }
handled |= CSR_INT_BIT_RF_KILL;
}
Nevertheless, I'm wondering if the current behaviour (even with the patch above)
makes much sense. I mean, the user space cannot rely on the rfkill state
unless an appropriate interface is up. As the device is able to report the
killswitch state without firmware being loaded the following approach could
be feasible:
- iwl_pci_probe enables the device and enables the interrupts
- iwl_mac_start just loads the firmware
- iwl_mac_stop just releases the firmware but leaves the interrupts enabled
Thanks,
Helmut
Hi Henrique,
> > if the hardware/firmware doesn't allow us to do so, we have no real
> > option. I think that nobody thought about this use case so far. I am not
> > sure if we should unregister it or just fix rfkill to add an invalid
> > state. It is also possible to tie rfkill with ifup/ifdown.
>
> Please don't register/unregister rfkill classes like that, it is extremely
> broken from userspace's point-of-view, and it is not how the rfkill core
> subsystem expects things to be used either. If there is no way to avoid
> register/unregister at interface up/down, it is better to never register any
> rfkill classes at all, and remove the functionality.
>
> Now, I hate when people use the term "rfkill switch" when dealing with the
> kernel rfkill subsystem, because we can't really always be sure we
> understood what the person means, so please bear with me...
>
> Are you talking about the hardware rfkill line (the input pin where one
> might have hooked an input device)? Or about something else?
so this case is that we are not getting any updates about the rfkill
line status if the firmware is not loaded (happens at ifdown case). How
do you propose this should be handled?
Regards
Marcel
Am Montag, 1. Dezember 2008 schrieb John W. Linville:
> FWIW, I'm not sure what the point of checking rfkill state would be if the
> adapter is down anyway. Hmmm...maybe management of the rfkill LED?
The main intention was that user space programs might want to listen to rfkill
events in order to bring the interface up once the killswitch is disabled.
AFAIK NetworkManager takes an interface down once it recognises that the
device is disabled through a killswitch. If the device is not able to notify
a rfkill state change if it is down NM cannot recognise when the device can
be brought up again.
Dan, is that correct?
Regards,
Helmut
On Mon, 01 Dec 2008, Marcel Holtmann wrote:
> if the hardware/firmware doesn't allow us to do so, we have no real
> option. I think that nobody thought about this use case so far. I am not
> sure if we should unregister it or just fix rfkill to add an invalid
> state. It is also possible to tie rfkill with ifup/ifdown.
Please don't register/unregister rfkill classes like that, it is extremely
broken from userspace's point-of-view, and it is not how the rfkill core
subsystem expects things to be used either. If there is no way to avoid
register/unregister at interface up/down, it is better to never register any
rfkill classes at all, and remove the functionality.
Now, I hate when people use the term "rfkill switch" when dealing with the
kernel rfkill subsystem, because we can't really always be sure we
understood what the person means, so please bear with me...
Are you talking about the hardware rfkill line (the input pin where one
might have hooked an input device)? Or about something else?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Mon, Dec 1, 2008 at 5:04 PM, Helmut Schaa
<[email protected]> wrote:
> Am Montag, 1. Dezember 2008 schrieb Tomas Winkler:
>> On Mon, Dec 1, 2008 at 2:11 PM, Helmut Schaa
>> <[email protected]> wrote:
>
> ...
>
>> > diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
>> > index b935e9d..e2f160b 100644
>> > --- a/drivers/net/wireless/iwlwifi/iwl-agn.c
>> > +++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
>> > @@ -1504,8 +1504,11 @@ static void iwl_irq_tasklet(struct iwl_priv *priv)
>> > * the driver as well won't allow loading if RFKILL is set
>> > * therefore no need to restart the driver from this handler
>> > */
>> > - if (!hw_rf_kill && !test_bit(STATUS_ALIVE, &priv->status))
>> > + if (!hw_rf_kill && !test_bit(STATUS_ALIVE, &priv->status)) {
>> > clear_bit(STATUS_RF_KILL_HW, &priv->status);
>> > + if (priv->is_open)
>> > + queue_work(priv->workqueue, &priv->restart);
>> > + }
>> >
>> > handled |= CSR_INT_BIT_RF_KILL;
>> > }
>>
>> This is strange, this exact code is part of patch
>> """
>> Emmanuel Grumbach <[email protected]>
>> Date: Sun Jun 22 11:18:52 2008 +0300
>> iwlwifi: clean up HW RF-kill state machine and restarts
>> This patch cleans up HW RF-kill state machine.
>> """
>> The two other hunks of this patch are in the current code, this one is
>> not, I've probably messed up something on they way. I will track this
>> down.
>
> Thanks, should I respin the above patch?
Sorry I was wrong about the patch. The correct one is
http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-2.6.git;a=commitdiff;h=a91ad840c23a70bc0eabe239e178e0d979a6d44e;hp=5ef81ff85d135e83eff581237de41a362cbdb167
It few problems and I've actually I had it rebased over current code
and started to clean it up but then there were series of unexpected
events which brought it to darkness.
One think for sure what need to be removed form the patch is setting
radio_enabled within the driver code Although mac80211 awareness of
rfkill is still not addressed.
Anyhow If you have free afternoon you can pick up the patch otherwise
somebody from intel will
>
>> > Nevertheless, I'm wondering if the current behaviour (even with the patch above)
>> > makes much sense. I mean, the user space cannot rely on the rfkill state
>> > unless an appropriate interface is up. As the device is able to report the
>> > killswitch state without firmware being loaded the following approach could
>> > be feasible:
>> > - iwl_pci_probe enables the device and enables the interrupts
>> > - iwl_mac_start just loads the firmware
>> > - iwl_mac_stop just releases the firmware but leaves the interrupts enabled
>>
>> In 3495 rfkill interrupt is not available and rfkill state is
>> delivered only when firmware is loaded, therefore this is not
>> possible to bring device down and also expect rfill switch event.
>
> Would it be possible to poll CSR_GP_CNTRL for that information on iwl3945?
Not sure, need to run and check
>
>> There were few threads about this subject.
>
> Searching for these now ...
>
>> In 4965 and 5000 this will work
>
> Would you agree on that behavior?
> Any objections I did not think of yet?
This is definitely the way but it seems that patch is just it's not enough.
Thanks
Tomas
On Mon, Dec 1, 2008 at 2:11 PM, Helmut Schaa
<[email protected]> wrote:
> Hi,
>
> Since the patch "iwlwifi: delay firmware loading from pci_probe to network
> interface open" was merged, the driver's killswitch does not work anymore
> when the interface is down. The patch comment contains two arguments for
> that behaviour:
>
> 1) ... Because kernel initializes network devices subsystem before hard disk
> and SATA subsystem, it is impossible to get the firmware image from hard disk
> in the PCI probe handler. ...
>
> 2) For better power saving ...
>
> The current driver behavior is as follows:
>
> - iwl_pci_probe initializes the driver but disables the device, at this point
> changing the killswitch state will not be noticed by the driver and thus
> the killswitch state in sysfs will not reflect the real state
>
> - iwl_mac_start (which is called when at least one interface goes up) starts
> the device and loads the firmware if the killswitch is disabled. Otherwise
> the driver will just enable the interrupts and allows the interface to go
> up.
>
> However, if the device fires the interrupt CSR_INT_BIT_RF_KILL the code in
> iwl_irq_tasklet will _not_ restart the card, although the driver already
> allowed the interface to go up. That should easily be fixable with a patch
> similar to the following (the comment should be changed too):
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
> index b935e9d..e2f160b 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-agn.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
> @@ -1504,8 +1504,11 @@ static void iwl_irq_tasklet(struct iwl_priv *priv)
> * the driver as well won't allow loading if RFKILL is set
> * therefore no need to restart the driver from this handler
> */
> - if (!hw_rf_kill && !test_bit(STATUS_ALIVE, &priv->status))
> + if (!hw_rf_kill && !test_bit(STATUS_ALIVE, &priv->status)) {
> clear_bit(STATUS_RF_KILL_HW, &priv->status);
> + if (priv->is_open)
> + queue_work(priv->workqueue, &priv->restart);
> + }
>
> handled |= CSR_INT_BIT_RF_KILL;
> }
This is strange, this exact code is part of patch
"""
Emmanuel Grumbach <[email protected]>
Date: Sun Jun 22 11:18:52 2008 +0300
iwlwifi: clean up HW RF-kill state machine and restarts
This patch cleans up HW RF-kill state machine.
"""
The two other hunks of this patch are in the current code, this one is
not, I've probably messed up something on they way. I will track this
down.
> Nevertheless, I'm wondering if the current behaviour (even with the patch above)
> makes much sense. I mean, the user space cannot rely on the rfkill state
> unless an appropriate interface is up. As the device is able to report the
> killswitch state without firmware being loaded the following approach could
> be feasible:
> - iwl_pci_probe enables the device and enables the interrupts
> - iwl_mac_start just loads the firmware
> - iwl_mac_stop just releases the firmware but leaves the interrupts enabled
In 3495 rfkill interrupt is not available and rfkill state is
delivered only when firmware is loaded, therefore this is not
possible to bring device down and also expect rfill switch event.
There were few threads about this subject.
In 4965 and 5000 this will work
Thanks
Tomas
Am Montag, 1. Dezember 2008 schrieb Marcel Holtmann:
> Hi Helmut,
>
> > > > > Nevertheless, I'm wondering if the current behaviour (even with the patch above)
> > > > > makes much sense. I mean, the user space cannot rely on the rfkill state
> > > > > unless an appropriate interface is up. As the device is able to report the
> > > > > killswitch state without firmware being loaded the following approach could
> > > > > be feasible:
> > > > > - iwl_pci_probe enables the device and enables the interrupts
> > > > > - iwl_mac_start just loads the firmware
> > > > > - iwl_mac_stop just releases the firmware but leaves the interrupts enabled
> > > >
> > > > In 3495 rfkill interrupt is not available and rfkill state is
> > > > delivered only when firmware is loaded, therefore this is not
> > > > possible to bring device down and also expect rfill switch event.
> > > > There were few threads about this subject.
> > > > In 4965 and 5000 this will work
> > >
> > > do we unregister the rfkill switch when bringing the adapter down.
> >
> > No.
> >
> > > If not, then we might should do that. I don't see a point in exposing a
> > > rfkill switch if we can't do anything with it.
> >
> > Either that, or make the rfkill usable even when the interface is down.
>
> if the hardware/firmware doesn't allow us to do so, we have no real
> option.
Ah, you're talking about 3945. Missed that.
Helmut
Am Montag, 1. Dezember 2008 schrieb Tomas Winkler:
> On Mon, Dec 1, 2008 at 2:11 PM, Helmut Schaa
> <[email protected]> wrote:
...
> > diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
> > index b935e9d..e2f160b 100644
> > --- a/drivers/net/wireless/iwlwifi/iwl-agn.c
> > +++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
> > @@ -1504,8 +1504,11 @@ static void iwl_irq_tasklet(struct iwl_priv *priv)
> > * the driver as well won't allow loading if RFKILL is set
> > * therefore no need to restart the driver from this handler
> > */
> > - if (!hw_rf_kill && !test_bit(STATUS_ALIVE, &priv->status))
> > + if (!hw_rf_kill && !test_bit(STATUS_ALIVE, &priv->status)) {
> > clear_bit(STATUS_RF_KILL_HW, &priv->status);
> > + if (priv->is_open)
> > + queue_work(priv->workqueue, &priv->restart);
> > + }
> >
> > handled |= CSR_INT_BIT_RF_KILL;
> > }
>
> This is strange, this exact code is part of patch
>
> """
> Emmanuel Grumbach <[email protected]>
> Date: Sun Jun 22 11:18:52 2008 +0300
> iwlwifi: clean up HW RF-kill state machine and restarts
> This patch cleans up HW RF-kill state machine.
> """
> The two other hunks of this patch are in the current code, this one is
> not, I've probably messed up something on they way. I will track this
> down.
Thanks, should I respin the above patch?
> > Nevertheless, I'm wondering if the current behaviour (even with the patch above)
> > makes much sense. I mean, the user space cannot rely on the rfkill state
> > unless an appropriate interface is up. As the device is able to report the
> > killswitch state without firmware being loaded the following approach could
> > be feasible:
> > - iwl_pci_probe enables the device and enables the interrupts
> > - iwl_mac_start just loads the firmware
> > - iwl_mac_stop just releases the firmware but leaves the interrupts enabled
>
> In 3495 rfkill interrupt is not available and rfkill state is
> delivered only when firmware is loaded, therefore this is not
> possible to bring device down and also expect rfill switch event.
Would it be possible to poll CSR_GP_CNTRL for that information on iwl3945?
> There were few threads about this subject.
Searching for these now ...
> In 4965 and 5000 this will work
Would you agree on that behavior?
Any objections I did not think of yet?
Thanks,
Helmut
Hi Helmut,
> > > > Nevertheless, I'm wondering if the current behaviour (even with the patch above)
> > > > makes much sense. I mean, the user space cannot rely on the rfkill state
> > > > unless an appropriate interface is up. As the device is able to report the
> > > > killswitch state without firmware being loaded the following approach could
> > > > be feasible:
> > > > - iwl_pci_probe enables the device and enables the interrupts
> > > > - iwl_mac_start just loads the firmware
> > > > - iwl_mac_stop just releases the firmware but leaves the interrupts enabled
> > >
> > > In 3495 rfkill interrupt is not available and rfkill state is
> > > delivered only when firmware is loaded, therefore this is not
> > > possible to bring device down and also expect rfill switch event.
> > > There were few threads about this subject.
> > > In 4965 and 5000 this will work
> >
> > do we unregister the rfkill switch when bringing the adapter down.
>
> No.
>
> > If not, then we might should do that. I don't see a point in exposing a
> > rfkill switch if we can't do anything with it.
>
> Either that, or make the rfkill usable even when the interface is down.
if the hardware/firmware doesn't allow us to do so, we have no real
option. I think that nobody thought about this use case so far. I am not
sure if we should unregister it or just fix rfkill to add an invalid
state. It is also possible to tie rfkill with ifup/ifdown.
Regards
Marcel
On Mon, 2008-12-01 at 22:50 +0100, Helmut Schaa wrote:
> Am Montag, 1. Dezember 2008 schrieb John W. Linville:
> > FWIW, I'm not sure what the point of checking rfkill state would be if the
> > adapter is down anyway. Hmmm...maybe management of the rfkill LED?
>
> The main intention was that user space programs might want to listen to rfkill
> events in order to bring the interface up once the killswitch is disabled.
>
> AFAIK NetworkManager takes an interface down once it recognises that the
> device is disabled through a killswitch. If the device is not able to notify
> a rfkill state change if it is down NM cannot recognise when the device can
> be brought up again.
>
> Dan, is that correct?
Yes, but *only* because the rfkill layer < 2.6.27 (and still HAL
doesn't) didn't have any support for SOFT_BLOCK. Once HAL grows support
for 3 states (HW_BLOCK, SW_BLOCK, UNBLOCKED) in its killswitch objects,
then I'll:
1) switch NM over to use SOFT_BLOCK when "disabling wireless", or if
there is no killswitch then just turn off the TX power with SIOCSIWTXPOW
2) Not take the interface down at all, but ensure that rfkill has
occurred
The only reason that NM takes the interface down is that previously,
this was the way to ensure that the radio was not transmitting.
Unfortunately, that also unloads firmware on iwl3945, meaning that the
3945 (and thus NM) cannot detect unblocking of the 3945 radio.
The reason we cannot use SIOCSIWTXPOW today is that with ipw2100,
ipw2200, and ipw2915, HAL reports that the radio is HW_BLOCKed and thus
there's no way to know that the radio can be unblocked via software
(like the applet menu).
Dan
On Mon, Dec 01, 2008 at 04:59:11PM +0100, Marcel Holtmann wrote:
> Hi Helmut,
>
> > > > > Nevertheless, I'm wondering if the current behaviour (even with the patch above)
> > > > > makes much sense. I mean, the user space cannot rely on the rfkill state
> > > > > unless an appropriate interface is up. As the device is able to report the
> > > > > killswitch state without firmware being loaded the following approach could
> > > > > be feasible:
> > > > > - iwl_pci_probe enables the device and enables the interrupts
> > > > > - iwl_mac_start just loads the firmware
> > > > > - iwl_mac_stop just releases the firmware but leaves the interrupts enabled
> > > >
> > > > In 3495 rfkill interrupt is not available and rfkill state is
> > > > delivered only when firmware is loaded, therefore this is not
> > > > possible to bring device down and also expect rfill switch event.
> > > > There were few threads about this subject.
> > > > In 4965 and 5000 this will work
> > >
> > > do we unregister the rfkill switch when bringing the adapter down.
> >
> > No.
> >
> > > If not, then we might should do that. I don't see a point in exposing a
> > > rfkill switch if we can't do anything with it.
I think this is a good suggestion.
> > Either that, or make the rfkill usable even when the interface is down.
>
> if the hardware/firmware doesn't allow us to do so, we have no real
> option. I think that nobody thought about this use case so far. I am not
> sure if we should unregister it or just fix rfkill to add an invalid
> state. It is also possible to tie rfkill with ifup/ifdown.
I don't see much point in an invalid state -- just deregister as you
suggested above.
FWIW, I'm not sure what the point of checking rfkill state would be if the
adapter is down anyway. Hmmm...maybe management of the rfkill LED?
John
--
John W. Linville Linux should be at the core
[email protected] of your literate lifestyle.
Hello Marcel,
On Tue, 02 Dec 2008, Marcel Holtmann wrote:
> > > if the hardware/firmware doesn't allow us to do so, we have no real
> > > option. I think that nobody thought about this use case so far. I am not
> > > sure if we should unregister it or just fix rfkill to add an invalid
> > > state. It is also possible to tie rfkill with ifup/ifdown.
> >
> > Please don't register/unregister rfkill classes like that, it is extremely
> > broken from userspace's point-of-view, and it is not how the rfkill core
> > subsystem expects things to be used either. If there is no way to avoid
> > register/unregister at interface up/down, it is better to never register any
> > rfkill classes at all, and remove the functionality.
> >
> > Now, I hate when people use the term "rfkill switch" when dealing with the
> > kernel rfkill subsystem, because we can't really always be sure we
> > understood what the person means, so please bear with me...
> >
> > Are you talking about the hardware rfkill line (the input pin where one
> > might have hooked an input device)? Or about something else?
>
> so this case is that we are not getting any updates about the rfkill
> line status if the firmware is not loaded (happens at ifdown case). How
> do you propose this should be handled?
The hardware rfkill line? If it is the hardware rfkill line, I have some
ideas. Some are better for the user, but much harder to implement...
1. Poll it @1Hz or 0.5Hz while the firmware is down if it makes sense (i.e.
if the whole process needed to poll (which might well mean start the
firmware, poll, stop it) is not worse than keeping the firmware running all
the time in the first place).
2. Have a powersave firmware that you upload to the card instead of shutting
it down, and have that firmware still report hardware rfkill line changes.
This one is probably the ideal solution.
3. Consider alternate ways of power saving. E.g. you could soft-rfkill the
radio (but you must HIDE this from the rfkill core!) every time no
interfaces that can cause data transmission are open, if that would save
power but still leave the firmware running to get events.
4. Provide the user with a runtime tunable, which lets him disable the
firmware shutdown when closed. This is important for users of platforms
where the ipw card is the only way to get the status of the input device
driving hardware rfkill.
I expect many users will be able to run with the opportunistic firmware
shutdown optimization enabled without even noticing it much, as you often
can read the input device responsible for driving platform-wide hardware
rfkill lines from some other place (like vendor-specific ACPI nodes), and a
platform driver will take care of it.
Anyway, please make sure you manually poll and update the rfkill core state
through a call to rfkill_force_state() as soon as possible after you start
the firmware, if it was stopped for any reason and you might have lost
hardware rfkill line state change events.
I have also looked at the question from various povs, and my conclusion is
that, if we cannot avoid it at all, it is probably going to be annoying as
all heck to userspace but we may have to add a way for the rfkill core to
return -EBUSY when the current rfkill state is unknown.
I don't recommend adding a STATE_UKNOWN to rfkill. It is useless for
anything else, and it will get in the way everywhere in the rfkill core and
userspace. It is much better to just return a suitable error to userspace
when it queries the rfkill state.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Hi Tomas,
> > Nevertheless, I'm wondering if the current behaviour (even with the patch above)
> > makes much sense. I mean, the user space cannot rely on the rfkill state
> > unless an appropriate interface is up. As the device is able to report the
> > killswitch state without firmware being loaded the following approach could
> > be feasible:
> > - iwl_pci_probe enables the device and enables the interrupts
> > - iwl_mac_start just loads the firmware
> > - iwl_mac_stop just releases the firmware but leaves the interrupts enabled
>
> In 3495 rfkill interrupt is not available and rfkill state is
> delivered only when firmware is loaded, therefore this is not
> possible to bring device down and also expect rfill switch event.
> There were few threads about this subject.
> In 4965 and 5000 this will work
do we unregister the rfkill switch when bringing the adapter down. If
not, then we might should do that. I don't see a point in exposing a
rfkill switch if we can't do anything with it.
Regards
Marcel
Am Montag, 1. Dezember 2008 schrieb Marcel Holtmann:
> Hi Tomas,
>
> > > Nevertheless, I'm wondering if the current behaviour (even with the patch above)
> > > makes much sense. I mean, the user space cannot rely on the rfkill state
> > > unless an appropriate interface is up. As the device is able to report the
> > > killswitch state without firmware being loaded the following approach could
> > > be feasible:
> > > - iwl_pci_probe enables the device and enables the interrupts
> > > - iwl_mac_start just loads the firmware
> > > - iwl_mac_stop just releases the firmware but leaves the interrupts enabled
> >
> > In 3495 rfkill interrupt is not available and rfkill state is
> > delivered only when firmware is loaded, therefore this is not
> > possible to bring device down and also expect rfill switch event.
> > There were few threads about this subject.
> > In 4965 and 5000 this will work
>
> do we unregister the rfkill switch when bringing the adapter down.
No.
> If not, then we might should do that. I don't see a point in exposing a
> rfkill switch if we can't do anything with it.
Either that, or make the rfkill usable even when the interface is down.
Helmut
Am Montag, 1. Dezember 2008 schrieb Tomas Winkler:
> >> In 3495 rfkill interrupt is not available and rfkill state is
> >> delivered only when firmware is loaded, therefore this is not
> >> possible to bring device down and also expect rfill switch event.
> >
> > Would it be possible to poll CSR_GP_CNTRL for that information on iwl3945?
>
> Not sure, need to run and check
JFYI, I've just checked that:
It is possible to poll CSR_GP_CNTRL without the firmware begin loaded.
Hence the 3945 could also report the killswitch state to userspace while
being "down" by polling (instead of listening to interrupts like 4965).
Helmut