From: "Toke Høiland-Jørgensen" <toke@kernel.org>
To: Jonas Jelonek <jelonek.jonas@gmail.com>
Cc: linux-wireless@vger.kernel.org,
"Thomas Hühn" <thomas.huehn@hs-nordhausen.de>,
"Felix Fietkau" <nbd@nbd.name>,
kvalo@kernel.org, johannes.berg@intel.com, lorenzo@kernel.org
Subject: Re: [PATCH] ath9k: fix per-packet TX-power cap for TPC
Date: Thu, 30 Mar 2023 14:34:52 +0200 [thread overview]
Message-ID: <87tty2mn83.fsf@toke.dk> (raw)
In-Reply-To: <86B6FAF2-49B4-4993-A22D-FE102756AFD1@gmail.com>
Jonas Jelonek <jelonek.jonas@gmail.com> writes:
>> On 30. Mar 2023, at 11:31, Toke Høiland-Jørgensen <toke@kernel.org> wrote:
>>
>> 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 did not apply this shift,
>>> thus retrieved the incorrect maximum power level. For example, the
>>> maximum power for OFDM rate 0 was used for MCS rate 0. If STBC was used,
>>> the power was mostly limited to 0 because the STBC table is zeroed for
>>> legacy CCK/OFDM rates. This patch fixes this table lookup.
>>>
>>> Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
>>
>> So what effect does this bug have in practice? Also, how did you test
>> the patch? :)
>>
>
> It actually may not have an effect in most of current practical applications. The
> member ‘tpc_enabled' in struct ath_hw is by default set to false and thus, TPC
> in ath9k is usually disabled. The code path will be skipped in that case.
> But it has an effect as I am still working on TPC per packet in ath9k as part of
> research. Looking at my traces I saw that the TX-power is capped at 0 for
> MCS rates 0-7 in case the STBC flag is set in struct ieee80211_tx_info. Thus,
> transmission was significantly worse as usual, and I also was not able to
> manually set a proper TX-power via my testing API. With other rates it is working
> fine. I also double-checked that it isn’t a problem of how TX-power is set and
> reported with our upcoming API.
>
> I tested this with my OpenWrt-based AP-STA desk setup using two different
> ath9k wifi chips (AR9280, AR9580), Kernel 5.15.98. I guess that should be
> sufficient as ath9k hasn’t changed that significantly since that and several
> changes are already backported. I compile-tested it with latest 6.3 kernel
> (+allyesconfig), the patch applied flawlessly and encountered no problems.
> After applying my patch, I could see that everything was working as expected.
> Transmission performs equally as if TPC was disabled, and setting + reporting
> TX-power was working again. Also verified this with some verbose debugging
> in ath_get_rate_txpower to see which index + max power is used.
Alright, cool! Could you please add all this to the commit message and
resubmit?
-Toke
next prev parent reply other threads:[~2023-03-30 12:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-30 7:18 [PATCH] ath9k: fix per-packet TX-power cap for TPC Jonas Jelonek
2023-03-30 9:31 ` Toke Høiland-Jørgensen
2023-03-30 10:37 ` Jonas Jelonek
2023-03-30 12:34 ` Toke Høiland-Jørgensen [this message]
2023-03-30 13:21 ` Jonas Jelonek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tty2mn83.fsf@toke.dk \
--to=toke@kernel.org \
--cc=jelonek.jonas@gmail.com \
--cc=johannes.berg@intel.com \
--cc=kvalo@kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=nbd@nbd.name \
--cc=thomas.huehn@hs-nordhausen.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox