Bug 33982 - ath9k: regulatory: strange tx power limits
ath9k: regulatory: strange tx power limits
Status: CLOSED CODE_FIX
Product: Networking
Classification: Unclassified
Component: Wireless
All Linux
: P1 normal
Assigned To: networking_wireless@kernel-bugs.osdl.org
:
Depends on:
Blocks: 27352
  Show dependency treegraph
 
Reported: 2011-04-26 18:37 UTC by Richard Schütz
Modified: 2011-08-16 17:38 UTC (History)
7 users (show)

See Also:
Kernel Version: 2.6.38
Tree: Mainline
Regression: Yes


Attachments
relevant excerpt from dmesg (4.68 KB, text/plain)
2011-05-11 18:33 UTC, Richard Schütz
Details
ath9k_test.patch (1.95 KB, text/plain)
2011-06-05 09:02 UTC, Stanislaw Gruszka
Details
ath9k_test2.patch (556 bytes, text/plain)
2011-06-05 16:18 UTC, Stanislaw Gruszka
Details
ath9k_print_ratesArray.patch (3.77 KB, text/plain)
2011-07-18 14:43 UTC, Stanislaw Gruszka
Details
ath9k_print_ratesArray_v2.patch (4.89 KB, text/plain)
2011-07-19 04:21 UTC, Stanislaw Gruszka
Details
dmesg excerpt with debug information (without ath9k_test2.patch) (19.80 KB, text/plain)
2011-07-19 15:44 UTC, Richard Schütz
Details
dmesg excerpt with debug information (with ath9k_test2.patch) (13.42 KB, text/plain)
2011-07-19 15:45 UTC, Richard Schütz
Details
ath9k_remove_u8_cast.patch (493 bytes, text/plain)
2011-07-21 08:48 UTC, Stanislaw Gruszka
Details
dmesg excerpt with debug information (with ath9k_remove_u8_cast.patch) (18.74 KB, text/plain)
2011-07-21 11:21 UTC, Richard Schütz
Details
ath9k_print_ratesArray_v3.patch (6.80 KB, text/plain)
2011-07-25 14:49 UTC, Stanislaw Gruszka
Details
dmesg debug excerpt (ath9k_print_ratesArray_v3.patch) (61.00 KB, text/plain)
2011-07-26 15:22 UTC, Richard Schütz
Details
dmesg debug excerpt (ath9k_print_ratesArray_v3.patch + ath9k_test2.patch) (38.59 KB, text/plain)
2011-07-26 15:23 UTC, Richard Schütz
Details
ath9k_print_ratesArray_v4.patch (6.88 KB, text/plain)
2011-07-27 12:00 UTC, Stanislaw Gruszka
Details
ath9k_recalculate_txpower_limits_when_regd_change.patch (829 bytes, text/plain)
2011-07-27 12:02 UTC, Stanislaw Gruszka
Details
dmesg debug excerpt (ath9k_print_ratesArray_v4.patch) (63.71 KB, text/plain)
2011-07-27 12:41 UTC, Richard Schütz
Details
dmesg debug excerpt (ath9k_print_ratesArray_v4.patch + ath9k_test2.patch) (38.99 KB, text/plain)
2011-07-27 12:41 UTC, Richard Schütz
Details
ath9k_print_ratesArray_v5.patch (8.07 KB, text/plain)
2011-07-27 13:11 UTC, Stanislaw Gruszka
Details
dmesg debug excerpt (ath9k_print_ratesArray_v5.patch) (251.29 KB, text/plain)
2011-07-27 13:44 UTC, Richard Schütz
Details
dmesg debug excerpt (ath9k_print_ratesArray_v5.patch + ath9k_test2.patch) (157.02 KB, text/plain)
2011-07-27 13:44 UTC, Richard Schütz
Details
dmesg debug excerpt (ath9k: initialize tx chainmask before testing channel tx power values + ath9k_print_ratesArray_v2.patch) (18.73 KB, text/plain)
2011-07-27 14:44 UTC, Richard Schütz
Details

Description Richard Schütz 2011-04-26 18:37:41 UTC
I noticed that the tx power limits for my Atheros AR9285 are quite strange since kernel 2.6.38, though the correct regulatory domain is set. Other wireless adapters are working fine, so this seems to be a problem with the Atheros drivers.

excerpt from "iw list":
                Frequencies:
                        * 2412 MHz [1] (17.0 dBm)
                        * 2417 MHz [2] (17.0 dBm)
                        * 2422 MHz [3] (9.0 dBm)
                        * 2427 MHz [4] (13.0 dBm)
                        * 2432 MHz [5] (13.0 dBm)
                        * 2437 MHz [6] (13.0 dBm)
                        * 2442 MHz [7] (13.0 dBm)
                        * 2447 MHz [8] (13.0 dBm)
                        * 2452 MHz [9] (9.0 dBm)
                        * 2457 MHz [10] (14.0 dBm)
                        * 2462 MHz [11] (14.0 dBm)
                        * 2467 MHz [12] (17.0 dBm) (passive scanning)
                        * 2472 MHz [13] (17.0 dBm) (passive scanning)
                        * 2484 MHz [14] (disabled)

Normally 20 dBm tx power should by allowed for channel 1-13 regarding the regulatory domain:
country DE:
        (2400 - 2483 @ 40), (N/A, 20)
        (5150 - 5250 @ 40), (N/A, 20), NO-OUTDOOR
        (5250 - 5350 @ 40), (N/A, 20), NO-OUTDOOR, DFS
        (5470 - 5725 @ 40), (N/A, 26), DFS
Comment 1 John W. Linville 2011-05-11 16:37:11 UTC
Please post the output of dmesg from shortly after a reboot.
Comment 2 Richard Schütz 2011-05-11 18:33:24 UTC
Created attachment 57392 [details]
relevant excerpt from dmesg
Comment 3 John W. Linville 2011-05-11 20:21:00 UTC
Looks right to me...your hardware is defining the available settings...

[    7.790913] ath: EEPROM regdomain: 0x65
[    7.790920] ath: EEPROM indicates we should expect a direct regpair map
[    7.790928] ath: Country alpha2 being used: 00
[    7.790932] ath: Regpair used: 0x65

From drivers/net/wireless/ath/regd.c:

        switch (reg->regpair->regDmnEnum) {
...
        case 0x63:
        case 0x65:
                return &ath_world_regdom_63_65;

static const struct ieee80211_regdomain ath_world_regdom_63_65 = {
        .n_reg_rules = 4,
        .alpha2 =  "99",
        .reg_rules = {
                ATH9K_2GHZ_CH01_11,
                ATH9K_2GHZ_CH12_13,
                ATH9K_5GHZ_NO_MIDBAND,
        }
};
Comment 4 Richard Schütz 2011-05-12 04:47:04 UTC
You are talking about the frequency ranges, which are definitely correct, but this is not the topic!
I am talking about the transmission power limits, that are totally wrong. According to the regulatory domain for my country 20 dBm for each 2.4 GHz channel from 1 to 13 is allowed. But since 2.6.38 there are 17 dBm, 9 dBm, 13 dBm and 14 dBm limits assigned to the channels. This only happens with my Atheros and not with other wireless adapters.
Comment 5 John W. Linville 2011-05-12 15:00:38 UTC
Ah, OK...have you tried bisecting between 2.6.37 and 2.6.38?
Comment 6 Richard Schütz 2011-05-12 21:51:01 UTC
commit de40f316c01b1ba9535e6dc99f6a67e7655b07da
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Wed Oct 20 03:08:53 2010 +0200

    ath9k_hw: extend ath9k_hw_set_txpowerlimit to test channel txpower
    
    ath9k_hw_set_txpowerlimit gets an extra boolean parameter that - if set -
    causes the rate txpower table and the regulatory limit to be calculated
    and stored, without changing hardware registers.

That one looks very suspicious.
Comment 7 Richard Schütz 2011-05-12 22:43:08 UTC
Oh, I missed that that were multiple patches. I think these commits are responsible for the problem:

babcbc295fee766ca710235e431686fef744d9a6
de40f316c01b1ba9535e6dc99f6a67e7655b07da
6b7b6cf553f881d45bb37a73f5db956afb290a08
Comment 8 John W. Linville 2011-05-13 17:27:28 UTC
They definitely seem related to the issue.  Unfortunately, reverting them is a bit ugly...

Could you verify that edb40a23c8dc5b5be219bf4561074b6233bba65f works and that babcbc295fee766ca710235e431686fef744d9a6 is broken?
Comment 9 Richard Schütz 2011-05-13 17:52:12 UTC
edb40a23c8dc5b5be219bf4561074b6233bba65f can't be related, because it affects ath5k only.
Comment 10 John W. Linville 2011-05-13 17:56:57 UTC
Precisely -- it is the last commit before the three you identified. :-)
Comment 11 Richard Schütz 2011-05-23 16:41:15 UTC
Why is the status still NEEDINFO? How is the progress on this?
Comment 12 Florian Mickler 2011-05-23 17:28:19 UTC
The question was: Does the kernel edb40a23c8dc5b5be219bf4561074b6233bba65f work? 
In other words, did you test the corresponding kernel? (Comment #9 is not clear on that)
Comment 13 Richard Schütz 2011-05-23 18:51:01 UTC
I used different versions of compat-wireless to find the faulty commits, because I always ran into compilation errors when I used Linus' tree. edb40a23c8dc5b5be219bf4561074b6233bba65f does not compile here either.

compat-wireless-2010-11-09 is good and compat-wireless-2010-11-13 is bad.
Comment 14 noxenaz 2011-05-29 00:59:13 UTC
Same problem here
chipset: AR9285

iw list:
			* 2412 MHz [1] (17.0 dBm)
			* 2417 MHz [2] (17.0 dBm)
			* 2422 MHz [3] (9.0 dBm)
			* 2427 MHz [4] (13.0 dBm)
			* 2432 MHz [5] (13.0 dBm)
			* 2437 MHz [6] (13.0 dBm)
			* 2442 MHz [7] (13.0 dBm)
			* 2447 MHz [8] (13.0 dBm)
			* 2452 MHz [9] (9.0 dBm)
			* 2457 MHz [10] (14.0 dBm)
			* 2462 MHz [11] (14.0 dBm)
			* 2467 MHz [12] (17.0 dBm)
			* 2472 MHz [13] (17.0 dBm)
			* 2484 MHz [14] (disabled)

I using compat-wireless-2.6.39-1 + channel-negative-one-maxim.patch and 404-ath_regd_optional.patch
Comment 15 Richard Schütz 2011-06-04 19:12:31 UTC
Still no progress on this annoying bug?
Comment 16 Stanislaw Gruszka 2011-06-05 09:02:22 UTC
Created attachment 60832 [details]
ath9k_test.patch

This patch reverts small hunk of de40f316c01b1ba9535e6dc99f6a67e7655b07da that looks suspicious to me. Please test and report back, patch is for 2.6.38.
Comment 17 Richard Schütz 2011-06-05 09:44:38 UTC
(In reply to comment #16)
> Created an attachment (id=60832) [details]
> ath9k_test.patch
> 
> This patch reverts small hunk of de40f316c01b1ba9535e6dc99f6a67e7655b07da that
> looks suspicious to me. Please test and report back, patch is for 2.6.38.

Unfortunately, no change. iw still lists the same wrong tw power values.
Comment 18 Stanislaw Gruszka 2011-06-05 16:18:28 UTC
Created attachment 60852 [details]
ath9k_test2.patch

How about that one. This patch is effectively a revert of babcbc295fee766ca710235e431686fef744d9a6.
Comment 19 Richard Schütz 2011-06-05 16:42:44 UTC
(In reply to comment #18)
> Created an attachment (id=60852) [details]
> ath9k_test2.patch
> 
> How about that one. This patch is effectively a revert of
> babcbc295fee766ca710235e431686fef744d9a6.

Yeah, that one brings back the correct values.
Comment 20 Stanislaw Gruszka 2011-06-05 17:11:40 UTC
So, the bad commit is:

commit babcbc295fee766ca710235e431686fef744d9a6
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Wed Oct 20 02:09:46 2010 +0200

    ath9k: initialize per-channel tx power limits instead of hardcoding them

Felix, do you know how to fix this bug?
Comment 21 Florian Mickler 2011-06-11 10:50:48 UTC
First-Bad-Commit: babcbc295fee766ca710235e431686fef744d9a6
Comment 22 Felix Fietkau 2011-06-11 17:38:20 UTC
I think this commit only made the strange tx power limits visible, but did not cause them. Before this commit, hardware calibration data was not taken into account for the regulatory limit, instead it would not show what power limit the hardware was actually using.
Comment 23 Florian Mickler 2011-06-11 18:02:31 UTC
Richard, do you experience actual problems with ath9k having less tx-power, or were you just startled from the different values in iwlist?

Because, having the actual values and not the theoretical limits in iwlist sounds like a good thing to me... (Depending on the actual intended behaviour of course. I don't know that.)

Regards,
Flo
Comment 24 Richard Schütz 2011-06-11 18:30:02 UTC
Even if the commit only made the strange values visible they still look quite wrong to me. Is there a way to determine how powerful the hardware is really transmitting?

(In reply to comment #23)
> Richard, do you experience actual problems with ath9k having less tx-power, or
> were you just startled from the different values in iwlist?

Because I expected problems with the displayed lower values I never used "broken" kernels when I was on the move. So I can't say if there's really a difference at the moment.

PS: "iwlist" is not "iw list".
Comment 25 Florian Mickler 2011-06-26 13:50:59 UTC
I'm no expert, but what I would do is to check how the throughput behaves with distance to the ap. If the tx/rx-power is less with one kernel, you should be able to see a throughput difference (if you are far away from the ap). At least I would imagine. You'd have to be careful that the conditions (other wireless traffic in the vincinity) are similar though.
Comment 26 Stanislaw Gruszka 2011-07-18 14:43:43 UTC
Created attachment 65902 [details]
ath9k_print_ratesArray.patch

This patch prints ratesArray, i.e. per rate tx power setting we program device.

On my device there is no difference between programmed power setting with and without reverting "bad" commit. However ratesArray is calculated differently (and of course "iw list" output is different). I.e for 2.412 GHz I have:

Without comment 18 patch:
> ath9k_hw_def_set_txpower chan 2412 antRed 0 maxReg 40 limit 63 test 1
> 34, 34, 34, 34, 34, 34, 32, 30, 34, 34, 34, 34, 34, 34, 34, 34, 32, 32, 32, 32, 32, 28, 22, 20, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  max_power_lever 34
[snip]
> ath9k_hw_def_set_txpower chan 2412 antRed 0 maxReg 34 limit 63 test 0
> 28, 28, 28, 28, 28, 28, 28, 28, 32, 32, 32, 32, 32, 32, 32, 28, 27, 27, 27, 27, 27, 27, 22, 20, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  max_power_lever 32

With comment 18 patch:
> ath9k_hw_def_set_txpower chan 2412 antRed 0 maxReg 40 limit 63 test 0
> 28, 28, 28, 28, 28, 28, 28, 28, 32, 32, 32, 32, 32, 32, 32, 28, 27, 27, 27, 27, 27, 27, 22, 20, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  max_power_lever 32

You can check if power settings are different on your device. If they are the same, the new kernels should work the same as older ones. If not we have a regression.

Of course, ideally if device could operate at full regulatory allowed tx power on each channel/rate, but this problem is not regression, and it's very hardware specific, probably only Atheros folks could fix it.
Comment 27 Richard Schütz 2011-07-18 17:17:55 UTC
(In reply to comment #26)
> Created an attachment (id=65902) [details]
> ath9k_print_ratesArray.patch
> 
> This patch prints ratesArray, i.e. per rate tx power setting we program device.

I have applied your patch on 2.6.39.3 and I don't get any additional output.
Comment 28 Stanislaw Gruszka 2011-07-19 04:21:33 UTC
Created attachment 65952 [details]
ath9k_print_ratesArray_v2.patch

I forgot add printk in ar9003_eeprom.c, now information should be printed.
Comment 29 Richard Schütz 2011-07-19 08:17:19 UTC
(In reply to comment #28)
> Created an attachment (id=65952) [details]
> ath9k_print_ratesArray_v2.patch
> 
> I forgot add printk in ar9003_eeprom.c, now information should be printed.

Still nothing.
Comment 30 Stanislaw Gruszka 2011-07-19 14:21:33 UTC
Patch looks fine. Are you looking at dmesg ? :-) If so, please double check if you correct apply the patch, use patched kernel, etc ...
Comment 31 Richard Schütz 2011-07-19 15:44:14 UTC
Created attachment 66092 [details]
dmesg excerpt with debug information (without ath9k_test2.patch)
Comment 32 Richard Schütz 2011-07-19 15:45:59 UTC
Created attachment 66102 [details]
dmesg excerpt with debug information (with ath9k_test2.patch)

Now the debug output was displayed. Probably I had to less coffee this morning as I tried the first time.

There's definitely a difference concerning the power levels when ath9k_test2.patch is applied.
Comment 33 Stanislaw Gruszka 2011-07-20 13:18:12 UTC
Indeed, on some channels we transmit at half power. For example on 2.422 GHz channel: 

Wrong values:
> [    6.821219] ath9k_hw_4k_set_txpower chan 2422 antRed 0 maxReg 40 limit 63 test 1
> [    6.821281] 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  max_power_lever 19
[snip]
> [   17.337010] ath9k_hw_4k_set_txpower chan 2422 antRed 0 maxReg 18 limit 34 test 0
> [   17.337077] 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  max_power_lever 18

Correct values:
> [   17.053640] ath9k_hw_4k_set_txpower chan 2422 antRed 0 maxReg 40 limit 40 test 0
> [   17.053707] 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 28, 26, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  max_power_lever 29

Looks like there is some flaw in ath9k_hw_4k_set_txpower(). For twiceMaxRegulatoryPower = 40 and powerLimit = 40 we get power value = 29, but for twiceMaxRegulatoryPower = 40 and powerLimit = 63 we get power value 19.
Comment 34 Stanislaw Gruszka 2011-07-20 13:36:40 UTC
Flaw in ath9k_hw_4k_set_txpower should be probably fixed. But I wonder if calculating channel max power values we do currently, by th9k_hw_set_txpowerlimit test mode, is good solution. Perhaps better would be better to take these values from regulatory database via cfg80211/CRDA ? Felix & Atheros folks, would such change be ok for You?
Comment 35 Felix Fietkau 2011-07-20 13:55:05 UTC
cfg80211/crda is already used to restrict the tx power further. 
I think the test mode is useful, because otherwise the user has no way of knowing the transmit power limitation of the hardware, and without the test, such bugs that can limit the hardware tx power would simply go unnoticed.
Comment 36 Stanislaw Gruszka 2011-07-21 08:48:16 UTC
Created attachment 66202 [details]
ath9k_remove_u8_cast.patch

This patch remove u8 (1 byte) cast, that possibly limit tx power values. Richard, does the patch make values similar like correct ones? If not, some more debugging patch(es) will be needed.
Comment 37 Richard Schütz 2011-07-21 11:21:06 UTC
Created attachment 66232 [details]
dmesg excerpt with debug information (with ath9k_remove_u8_cast.patch)

Still the wrong values with ath9k_remove_u8_cast.patch applied.
Comment 38 Stanislaw Gruszka 2011-07-25 14:49:16 UTC
Created attachment 66562 [details]
ath9k_print_ratesArray_v3.patch

This patch add printing variables from ath9k_hw_set_4k_power_per_rate_table.

Richard, please provide dmesg with this patch and as usual with and without ath9k_test2.patch for compare. Hopefully this would be enough to find problem, if not some more debug will be needed. Thanks.
Comment 39 Richard Schütz 2011-07-26 15:22:56 UTC
Created attachment 66742 [details]
dmesg debug excerpt (ath9k_print_ratesArray_v3.patch)
Comment 40 Richard Schütz 2011-07-26 15:23:41 UTC
Created attachment 66752 [details]
dmesg debug excerpt (ath9k_print_ratesArray_v3.patch + ath9k_test2.patch)
Comment 41 Stanislaw Gruszka 2011-07-27 11:58:03 UTC
The difference is between twiceMaxEdgePower

Good:
[   17.176998] numCtlModes = 3
[   17.177002] twiceMaxEdgePower = 29

Bad:
[    6.773197] numCtlModes = 3
[    6.773201] twiceMaxEdgePower = 19

twiceMaxEdgePower calculation seems do not depend on powerLimit or twiceMaxRegulatoryPower. Seems to be depended on EEPROM data, which should be constant, and cfgCtl (input value, unfortunately it is not printed by debug patch).

I assume difference is caused by cfgCtl. It is provided by ath9k_regd_get_ctl(regulatory, chan), so cfgCtl seems to be depended on regulatory domain.
Comment 42 Stanislaw Gruszka 2011-07-27 12:00:03 UTC
Created attachment 66812 [details]
ath9k_print_ratesArray_v4.patch

Add cfgCtl prints.
Comment 43 Stanislaw Gruszka 2011-07-27 12:02:37 UTC
Created attachment 66822 [details]
ath9k_recalculate_txpower_limits_when_regd_change.patch

This patch recalculate max_power setting when regulatory domain is changed. It could be possible fix. Richard please check if it change max_power_lever to proper values.
Comment 44 Richard Schütz 2011-07-27 12:41:39 UTC
Created attachment 66842 [details]
dmesg debug excerpt (ath9k_print_ratesArray_v4.patch)
Comment 45 Richard Schütz 2011-07-27 12:41:57 UTC
Created attachment 66852 [details]
dmesg debug excerpt (ath9k_print_ratesArray_v4.patch + ath9k_test2.patch)
Comment 46 Richard Schütz 2011-07-27 12:43:19 UTC
(In reply to comment #43)
> Created an attachment (id=66822) [details]
> ath9k_recalculate_txpower_limits_when_regd_change.patch
> 
> This patch recalculate max_power setting when regulatory domain is changed. It
> could be possible fix. Richard please check if it change max_power_lever to
> proper values.

No change.
Comment 47 Stanislaw Gruszka 2011-07-27 13:11:45 UTC
Created attachment 66882 [details]
ath9k_print_ratesArray_v5.patch

So my assumptions was wrong, cfgCtl is exactly the same in bad and good case :-(

This patch prints more variables from ath9k_hw_set_4k_power_per_rate_table(), it should make us closer to solve the problem.
Comment 48 Richard Schütz 2011-07-27 13:22:34 UTC
I tried Felix' patchset

[PATCH 1/4] ath9k: initialize tx chainmask before testing channel tx power values
[PATCH 2/4] ath9k_hw: remove the tx power index offset
[PATCH 3/4] ath9k_hw: fix calculated runtime tx power limit
[PATCH 4/4] ath9k_hw: do not limit initial tx power to 20 dbm

from linux-wireless, but that limits the tx power of every channel to 14 dBm (according to iw list).
Comment 49 Richard Schütz 2011-07-27 13:44:11 UTC
Created attachment 66892 [details]
dmesg debug excerpt (ath9k_print_ratesArray_v5.patch)
Comment 50 Richard Schütz 2011-07-27 13:44:33 UTC
Created attachment 66902 [details]
dmesg debug excerpt (ath9k_print_ratesArray_v5.patch + ath9k_test2.patch)
Comment 51 Stanislaw Gruszka 2011-07-27 13:59:17 UTC
Can you try only first patch from Felix' set:
ath9k: initialize tx chainmask before testing channel tx power values ?
Comment 52 Richard Schütz 2011-07-27 14:16:10 UTC
(In reply to comment #51)
> Can you try only first patch from Felix' set:
> ath9k: initialize tx chainmask before testing channel tx power values ?

Applying the first patch only is enough to get the same result (14 dBm limit for every channel).
Comment 53 Stanislaw Gruszka 2011-07-27 14:28:34 UTC
Ahhh, I think this could be correct. Device should transmit with same tx power, you can check using ath9k_print_ratesArray_v2.patch and compare with results from comment #32 . iw list display is different because it not show hardcoded 20dB but true values with device is really working at.
Comment 54 Richard Schütz 2011-07-27 14:44:27 UTC
Created attachment 66922 [details]
dmesg debug excerpt (ath9k: initialize tx chainmask before testing channel tx power values + ath9k_print_ratesArray_v2.patch)

Yeah, looks similar to #32. It's annoying that 'iw list' shows other values.
Comment 55 Stanislaw Gruszka 2011-07-29 13:59:36 UTC
Patch: http://marc.info/?l=linux-wireless&m=131177168201216&w=2
Comment 56 Stanislaw Gruszka 2011-07-29 14:12:55 UTC
(In reply to comment #54)
> Yeah, looks similar to #32. It's annoying that 'iw list' shows other values.
iw list show values which device transmit at (note max_power_lever showed in dmesg is 2*value, probably for make calculation easy). Currently we show true values, before babcbc295fee766ca710235e431686fef744d9a6 we showed hardcoded 20dB, no matter what was the real tx power device operate on. I'm considered regression caused by commit babcbc295fee766ca710235e431686fef744d9a6 (make device transmitting at low tx power on some channels) fixed by Felix' "initialize tx chainmask" patch. We currently transmit with the same tx power as before.

Perhaps these devices could operate at higher lever than 14dB. This is question for Atheros folks. But even if we have some other bug that limit tx power, it is not regression.
Comment 57 Florian Mickler 2011-08-04 19:30:40 UTC
So I take it, the patch from comment #55 is the final word on it and close this as patch-available.  

If it hit's mainline, we can close this bug.

Note You need to log in before you can comment on or make changes to this bug.