Re: [PATCH v2] ath9k: fix per-packet TX-power cap for TPC

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Jonas Jelonek <jelonek.jonas@gmail.com> writes:

> Fix incorrect usage of plain rate_idx as index into the max (power) per
> rate lookup table.
>
> For transmit power control (TPC), the ath9k driver maintains internal
> tables (in struct ath_hw) to store the max allowed power level per rate.
> They are used to limit a given TX-power according to regulatory and user
> limits in the TX-path per packet. The tables are filled in a predefined
> order, starting with values for CCK + OFDM rates and followed by the
> values for MCS rates. Thus, the maximum power levels for MCS do not
> start at index 0 in the table but are shifted by a fixed value.
>
> The TX-power limiting in ath_get_rate_txpower currently does not apply
> this shift, thus retrieves the incorrect maximum power level for a given
> rate. In particular for MCS rates, the maximum power levels for CCK/OFDM
> rates were used, e.g. maximum power for OFDM 0 was used for MCS 0. If
> STBC is used, the power is mostly limited to 0 because the STBC table
> is zeroed for legacy CCK/OFDM rates. Encountered this during testing of
> our work-in-progress TPC per packet for ath9k.
> This only has an effect when TPC is enabled in ath9k (tpc_enabled in
> struct ath_hw) which defaults to false. In this case it has a
> significant impact on the used TX-power, throughput + RSSI. Otherwise
> the affected code is just skipped and TX-power is limited with the
> hardware registers only. This patch fixes this table lookup.
>
> Tested on OpenWrt (kernel 5.15.98, but backported ath9k driver) with
> small desk setup using ath9k chips AR9280 and AR9580. Cap of TX-power is
> working properly for all rates now, throughput and RSSI as expected,
> equal to as if TPC was disabled.
> Compile-tested with latest 6.3 kernel + allyesconfig.
>
> Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>

Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>