Re: [PATCH] cfg80211: fix maximum tx power handling

[Felix Fietkau <nbd@openwrt.org>]

On 2011-02-04 8:42 PM, Mark Mentovai wrote:
> Luis R. Rodriguez wrote:
>> On Sun, Jan 30, 2011 at 9:01 AM, Mark Mentovai <mark@moxienet.com> wrote:
>>> Your patch also doesn’t work properly for me using the ath9k driver.
>>> With your patch, I wind up with an artificial power limit of 20dBm
>>> across the board, although the hardware limit is actually 25dBm on the
>>> AR9223 I’m testing with. This stems from the fact that ath9k doesn’t
>>> know how to properly compute the hardware limit.
>>> ath9k_init_txpower_limits is implemented on top of
>>> ath9k_hw_set_txpowerlimit, which uses a channel’s current max_power
>>> value as a basis for its computation. This means that it will either
>>> use the hard-coded initial value of 20dBm from CHAN2G and CHAN5G in
>>> drivers/net/wireless/ath/ath9k/init.c, or it will use world regulatory
>>> domain values (also 20dBm) set by ath_regd_init_wiphy calling
>>> wiphy_apply_custom_regulatory.
>>
>> The real limit on ath9k comes from analyzing the CTLs from the EEPROM,
>> and using that as a max when a CTL is present. The value from cfg80211
>> is simply a local regulatory one, the CTLs take this one step further
>> and are calibration specific to help optimize performance on every
>> frequency range.
> 
> Of course. My point was merely that the CTL-based calculations that
> ath9k does in ath9k_init_txpower_limits when it tries to set a better
> .max_power don’t even come out correctly, because they’re based on the
> initial values or on regdomain values. They’re not actually the
> hardware’s limits. I’m not even positive that there’s a single right
> “hardware transmit power limit per channel” value, unless you were to
> examine all of the possible rates and perhaps antenna configurations
> and other parameters. ath9k_init_txpower_limits doesn’t do this.
> That’s why I saw the patch restricting transmit power to be 20dBm even
> though the CTL data would allow higher power.
> 
> In other words, I think babcbc295fee766ca710235e431686fef744d9a6 was wrong.
Right, for testing the tx power, we need to override the
twiceMaxRegulatoryPower parameter that we pass to the set_txpower op.

Additionally, we could examine more rates, but I haven't seen any card
where higher rates have a higher tx power setting that lower rates. I
think Atheros internally also uses the tx power setting for the lowest rate.

Other than the different rates, I don't think you need to examine more
configurations. The power increase by using multiple chains is already
added to the max tx power value.

- Felix