diff mbox

2.6.33.2: Turn tx power off/on for Atheros card

Message ID g2wf69abfc31005060752w6876439cm45f5be68001c8382@mail.gmail.com
State Not Applicable, archived
Delegated to: David Miller
Headers show

Commit Message

Yegor Yefremov May 6, 2010, 2:52 p.m. UTC
On Wed, May 5, 2010 at 12:26 PM, Yegor Yefremov
<yegorslists@googlemail.com> wrote:
> I'm using kernel 2.6.33.2 with AR2413 WLAN card. Issuing
>
> iwconfig wlan0 txpower off
>
> turns txpower off. I can see this status by iwconfig wlan0 and the
> communication with AP terminates. But when I turn the txpower on
>
> iwconfig wlan0 txpower on
>
> nothing happens. Though iwconfig shows the previous tx power value.
> Only ifconfig wlan0 down and then up recovers the transmission.
>
> Is it a known bug or I'm doing something wrong?

I made some debugging and found out that after iwconfig wlan0 txpower
off dev_close() will be invoked, so that local->open_count will be 0.
The next time txpower on will be called, it will be checked if
local->open_count > 0 and this conditions fails, so no  hardware
configuration will be made.

I've made a quick and dirty hack, that opens the wireless device by
enabling the txpower, if it was closed before. Is there any proper
solution? Is it really necessary to close device to tunr txpower off?

Best regards,
Yegor

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Luis Rodriguez May 6, 2010, 10:16 p.m. UTC | #1
On Thu, May 6, 2010 at 7:52 AM, Yegor Yefremov
<yegorslists@googlemail.com> wrote:
> On Wed, May 5, 2010 at 12:26 PM, Yegor Yefremov
> <yegorslists@googlemail.com> wrote:
>> I'm using kernel 2.6.33.2 with AR2413 WLAN card. Issuing
>>
>> iwconfig wlan0 txpower off
>>
>> turns txpower off. I can see this status by iwconfig wlan0 and the
>> communication with AP terminates. But when I turn the txpower on
>>
>> iwconfig wlan0 txpower on
>>
>> nothing happens. Though iwconfig shows the previous tx power value.
>> Only ifconfig wlan0 down and then up recovers the transmission.
>>
>> Is it a known bug or I'm doing something wrong?
>
> I made some debugging and found out that after iwconfig wlan0 txpower
> off dev_close() will be invoked, so that local->open_count will be 0.
> The next time txpower on will be called, it will be checked if
> local->open_count > 0 and this conditions fails, so no  hardware
> configuration will be made.
>
> I've made a quick and dirty hack, that opens the wireless device by
> enabling the txpower, if it was closed before. Is there any proper
> solution? Is it really necessary to close device to tunr txpower off?

Depends on the type of interfaces you have. For a monitor device it
makes no sense to close the device as you should be able to still RX.
It also is possible to TX over a monitor device using frame injection
so technically setting tx power to off would just mute it and would
seem useful.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

Index: b/net/wireless/wext-compat.c
===================================================================
--- a/net/wireless/wext-compat.c	2010-04-30 05:02:05.000000000 +0200
+++ b/net/wireless/wext-compat.c	2010-05-06 16:31:20.000000000 +0200
@@ -15,6 +15,7 @@ 
 #include <linux/slab.h>
 #include <net/iw_handler.h>
 #include <net/cfg80211.h>
+#include "../mac80211/ieee80211_i.h"
 #include "wext-compat.h"
 #include "core.h"

@@ -824,6 +825,7 @@ 
 {
 	struct wireless_dev *wdev = dev->ieee80211_ptr;
 	struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
+	struct ieee80211_local *local = wiphy_priv(wdev->wiphy);
 	enum tx_power_setting type;
 	int dbm = 0;

@@ -861,6 +863,8 @@ 
 				type = TX_POWER_LIMITED;
 			}
 		}
+		if(!local->open_count)
+			dev_open(wdev->netdev);
 	} else {
 		rfkill_set_sw_state(rdev->rfkill, true);
 		schedule_work(&rdev->rfkill_sync);