[LEDE-DEV] ATH_USER_REGD maximum power limitation

[Sven Eckelmann]

Hi,

I've just played around a little bit with your CPTCFG_ATH_USER_REGD patch on 
an OM5P but without your change 79a768a90fa9 ("ath: do not apply broken power 
limits with ATH_USER_REGD") [1]. I was a little bit confused when the I 
changed the country code to SG and VN and the power was reduced to 16 dBm on 
channel 36. I've looked a little bit around and the wiphy_register function 
seems to copy this limit from sband->channels[i].max_power.

It seems that the reason for that is that the ath9k device starts up with the 
country code US (ath internal regpair 0x3a). ath9k_hw_set_txpowerlimit is then 
called with the test parameter set to true and at the end sets the max_power 
to 16. Or more in detail:

 * ath9k_hw_set_txpowerlimit is called with test parameter == true
 * chan->max_power is set to MAX_RATE_POWER / 2 (31)
 * ath9k_hw_apply_txpower is called
 * CTLs for FCC [2] are applied to the pPwrArray
 * pPwrArray contains 12.5 dBm as maximum txpower for some rate;
   or when adding the correction for two chains: 15.5 dBm
 * max_power_level is set to 31 (15.5 dBm * 2)
 * ath9k_hw_set_txpowerlimit sets chan->max_power to
   ceil(max_power_level /2) == 16

The reg code will now always apply this limit (16dBm) as maximum for this 
channel.

Would you think too that it would make more sense when the second max_power 
overwrite in ath9k_hw_set_txpowerlimit is only done when CPTCFG_ATH_USER_REGD 
is not enabled?

    -	if (test)
    +	if (test && !IS_ENABLED(CPTCFG_ATH_USER_REGD))
     		channel->max_power = DIV_ROUND_UP(reg->max_power_level, 2);

Kind regards,
	Sven

[1] This change btw. can lead to too high tx power settings on newer OpenMesh
    devices when switching to an country which should use ETSI CTLs for either
    2.4GHz or 5GHz
[2] This device is using the older (lower) FCC limits
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20170809/01614e99/attachment-0001.sig>