Discussion:
iwlwifi - rfkill only works if the interface is up
(too old to reply)
Helmut Schaa
2008-12-01 12:11:17 UTC
Permalink
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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomas Winkler
2008-12-01 13:08:39 UTC
Permalink
On Mon, Dec 1, 2008 at 2:11 PM, Helmut Schaa
Post by Helmut Schaa
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
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 ...
- 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
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 <emmanuel.grumbach-***@public.gmane.org>
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.
Post by Helmut Schaa
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
- 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Helmut Schaa
2008-12-01 15:04:05 UTC
Permalink
Post by Tomas Winkler
On Mon, Dec 1, 2008 at 2:11 PM, Helmut Schaa
...
Post by Tomas Winkler
Post by Helmut Schaa
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
"""
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?
Post by Tomas Winkler
Post by Helmut Schaa
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
- 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?
Post by Tomas Winkler
There were few threads about this subject.
Searching for these now ...
Post by Tomas Winkler
In 4965 and 5000 this will work
Would you agree on that behavior?
Any objections I did not think of yet?

Thanks,
Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomas Winkler
2008-12-01 17:43:28 UTC
Permalink
On Mon, Dec 1, 2008 at 5:04 PM, Helmut Schaa
Post by Helmut Schaa
Post by Tomas Winkler
On Mon, Dec 1, 2008 at 2:11 PM, Helmut Schaa
...
Post by Tomas Winkler
Post by Helmut Schaa
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
"""
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
Post by Helmut Schaa
Post by Tomas Winkler
Post by Helmut Schaa
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
- 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
Post by Helmut Schaa
Post by Tomas Winkler
There were few threads about this subject.
Searching for these now ...
Post by Tomas Winkler
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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Helmut Schaa
2009-01-05 14:43:21 UTC
Permalink
Post by Tomas Winkler
Post by Helmut Schaa
Post by 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann
2008-12-01 15:30:53 UTC
Permalink
Hi Tomas,
Post by Tomas Winkler
Post by Helmut Schaa
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
- 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


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Helmut Schaa
2008-12-01 15:34:36 UTC
Permalink
Post by Marcel Holtmann
Hi Tomas,
Post by Tomas Winkler
Post by Helmut Schaa
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
- 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.
Post by Marcel Holtmann
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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann
2008-12-01 15:59:11 UTC
Permalink
Hi Helmut,
Post by Helmut Schaa
Post by Marcel Holtmann
Post by Tomas Winkler
Post by Helmut Schaa
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
- 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.
Post by Marcel Holtmann
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


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Helmut Schaa
2008-12-01 16:16:41 UTC
Permalink
Post by Marcel Holtmann
Hi Helmut,
Post by Helmut Schaa
Post by Marcel Holtmann
Post by Tomas Winkler
Post by Helmut Schaa
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
- 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.
Post by Marcel Holtmann
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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
John W. Linville
2008-12-01 21:12:31 UTC
Permalink
Post by Marcel Holtmann
Hi Helmut,
Post by Helmut Schaa
Post by Marcel Holtmann
Post by Tomas Winkler
Post by Helmut Schaa
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
- 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.
Post by Marcel Holtmann
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.
Post by Marcel Holtmann
Post by Helmut Schaa
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
linville-***@public.gmane.org of your literate lifestyle.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Helmut Schaa
2008-12-01 21:50:36 UTC
Permalink
Post by 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Dan Williams
2008-12-03 22:48:40 UTC
Permalink
Post by Helmut Schaa
Post by 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


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Henrique de Moraes Holschuh
2008-12-02 12:59:59 UTC
Permalink
Post by Marcel Holtmann
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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann
2008-12-02 13:14:53 UTC
Permalink
Hi Henrique,
Post by Henrique de Moraes Holschuh
Post by Marcel Holtmann
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


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Henrique de Moraes Holschuh
2008-12-02 15:03:23 UTC
Permalink
Hello Marcel,
Post by Marcel Holtmann
Post by Henrique de Moraes Holschuh
Post by Marcel Holtmann
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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Continue reading on narkive:
Loading...