Re: [PATCH 1/2] ath5k: fix wrong per rate target power eeprom reads for AR5K_EEPROM_MODE_11A

[Felix Fietkau <nbd@openwrt.org>]

On 2012-07-25 8:42 PM, Nick Kossifidis wrote:
> 2012/7/23 Thomas Huehn <thomas@net.t-labs.tu-berlin.de>:
>> This patch reduces the per rate target power eeprom reads for
>> AR5K_EEPROM_MODE_11A from 10 to 8, as there are only 8 valid
>> power curve entries on the eeprom. The former 10 reads lead to
>> wrong per rate power limits where rates above 24MBit could be
>> amplified with to high distortion leading to bad performance.
>> This was fix validated against the madwifi codebase and a new
>> AR5K_EEPROM_N_5GHZ_RATE_CHAN 8 is defined.
>>
>> Signed-off-by: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
>> ---
>> madwifi cross validation check. Thx to Felix Fiethkau
>> ---
> 
> 
> Thanks for catching this but the bug is elsewhere:
> 
> I've tried to document hw code as much as I can, eeprom stuff is still
> missing and I'm sorry for that but here is what comments say on phy.c
> @ DOC: Per-rate tx power setting, that should give you an idea of
> what's happening...
> 
> 3498  * Rate power table contains indices to PCDAC/PDADC table (0.5dB steps -
> 3499  * x values) and is indexed as follows:
> 3500  * rates[0] - rates[7] -> OFDM rates
> 3501  * rates[8] - rates[14] -> CCK rates
> 3502  * rates[15] -> XR rates (they all have the same power)
> 
> So guess why the last 2 "invalid" power gain values have the same
> power levels for all rates ? They are for XR mode (they've put it
> there on the eeprom because XR mode also operates at 5GHz) and since
> XR stuff is stripped off Madwifi (at least the public HAL) that's why
> it only reads 8 of the piers.
It's not just stripped in the public HAL. Every driver that I've looked
at only reads 8 of the piers in the function that parses the EEPROM.

- Felix