Patchwork 2.6.33.2: Turn tx power off/on for Atheros card

login
register
mail settings
Submitter Yegor Yefremov
Date May 6, 2010, 2:52 p.m.
Message ID <g2wf69abfc31005060752w6876439cm45f5be68001c8382@mail.gmail.com>
Download mbox | patch
Permalink /patch/51836/
State Not Applicable
Delegated to: David Miller
Headers show

Comments

Yegor Yefremov - May 6, 2010, 2:52 p.m.
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
Luis Rodriguez - May 6, 2010, 10:16 p.m.
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

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);