[PATCH] mac80211: Fix wrong channel bandwidths reported for aggregates
Linus Lüssing
ll at simonwunderlich.de
Tue Jul 19 08:36:33 PDT 2022
On 19/07/2022 17:03, Adrian Chadd wrote:
> Hi!
>
> It's not a hardware bug. Dating back to the original AR5416 11n chip,
> most flags aren't valid for subframes in an aggregate. Only the final
> frame has valid flags. This was explicitly covered internally way back
> when.
Ah, thanks for the clarification! I see it in the datasheet for the
QCA9531, too, now. And thanks for the confirmation, that what we are
doing so far is not correct for ath9k.
Words 0+2 are valid for all RX descriptors, 0+2+11 valid for the last RX
descriptor of each packet and 0-11 for the last RX descriptor of an
aggregate or last RX descriptor of a stand-alone packet. Or in other
words, word 4, which contains the 20 vs. 40 MHz indicator, is invalid
for any aggregate sub-frame other than the last one. I can rename that
in the commit message.
Another approach that also came to my mind was introducing more explicit
flags in cfg80211.h's "struct rate_info", like a RATE_INFO_BW_UNKNOWN in
"enum rate_info_bw" and/or RATE_INFO_FLAGS_UNKNOWN in "enum
rate_info_flags". And setting those flags in ath9k_cmn_process_rate().
The current approach is smaller though, as it simply uses the already
existing flags. If anyone has any preferences, please let me know.
Regards, Linus
More information about the ath10k
mailing list