From: Kalle Valo <kvalo@codeaurora.org>
To: Wen Gong <wgong@codeaurora.org>
Cc: netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, ath10k@lists.infradead.org,
Shuah Khan <skhan@linuxfoundation.org>,
kuba@kernel.org, davem@davemloft.net
Subject: Re: [PATCH 5/5] ath10k: reduce invalid ht params rate message noise
Date: Wed, 10 Feb 2021 10:28:45 +0200 [thread overview]
Message-ID: <87h7mktjgi.fsf@codeaurora.org> (raw)
In-Reply-To: <5c31f6dadbcc3dcb19239ad2b6106773@codeaurora.org> (Wen Gong's message of "Wed, 10 Feb 2021 10:36:23 +0800")
Wen Gong <wgong@codeaurora.org> writes:
> On 2021-02-10 08:42, Shuah Khan wrote:
>> ath10k_mac_get_rate_flags_ht() floods dmesg with the following
>> messages,
>> when it fails to find a match for mcs=7 and rate=1440.
>>
>> supported_ht_mcs_rate_nss2:
>> {7, {1300, 2700, 1444, 3000} }
>>
>> ath10k_pci 0000:02:00.0: invalid ht params rate 1440 100kbps nss 2
>> mcs 7
>>
>> dev_warn_ratelimited() isn't helping the noise. Use dev_warn_once()
>> instead.
>>
>> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
>> ---
>> drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
>> b/drivers/net/wireless/ath/ath10k/mac.c
>> index 3545ce7dce0a..276321f0cfdd 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -8970,8 +8970,9 @@ static void ath10k_mac_get_rate_flags_ht(struct
>> ath10k *ar, u32 rate, u8 nss, u8
>> *bw |= RATE_INFO_BW_40;
>> *flags |= RATE_INFO_FLAGS_SHORT_GI;
>> } else {
>> - ath10k_warn(ar, "invalid ht params rate %d 100kbps nss %d mcs %d",
>> - rate, nss, mcs);
>> + dev_warn_once(ar->dev,
>> + "invalid ht params rate %d 100kbps nss %d mcs %d",
>> + rate, nss, mcs);
>> }
>> }
>
> The {7, {1300, 2700, 1444, 3000} } is a correct value.
> The 1440 is report from firmware, its a wrong value, it has fixed in
> firmware.
In what version?
> If change it to dev_warn_once, then it will have no chance to find the
> other wrong values which report by firmware, and it indicate
> a wrong value to mac80211/cfg80211 and lead "iw wlan0 station dump"
> get a wrong bitrate.
I agree, we should keep this warning. If the firmware still keeps
sending invalid rates we should add a specific check to ignore the known
invalid values, but not all of them.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2021-02-10 8:29 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-10 0:42 [PATCH 0/5] ath10k fixes for warns Shuah Khan
2021-02-10 0:42 ` [PATCH 1/5] ath10k: fix conf_mutex lock assert in ath10k_debug_fw_stats_request() Shuah Khan
2021-02-10 8:09 ` Kalle Valo
[not found] ` <20210210080915.8A81AC433C6@smtp.codeaurora.org>
2021-02-10 16:21 ` Shuah Khan
2021-02-10 0:42 ` [PATCH 2/5] ath10k: fix WARNING: suspicious RCU usage Shuah Khan
2021-02-10 8:13 ` Kalle Valo
[not found] ` <20210210081320.2FBE5C433CA@smtp.codeaurora.org>
2021-02-10 16:22 ` Shuah Khan
2021-02-10 0:42 ` [PATCH 3/5] ath10k: change ath10k_offchan_tx_work() peer present msg to a warn Shuah Khan
2021-02-11 6:50 ` Kalle Valo
2021-02-10 0:42 ` [PATCH 4/5] ath10k: detect conf_mutex held ath10k_drain_tx() calls Shuah Khan
2021-02-10 8:03 ` kernel test robot
2021-02-10 8:25 ` Kalle Valo
2021-02-10 15:57 ` Shuah Khan
2021-02-11 11:20 ` Kalle Valo
2021-02-11 20:53 ` Shuah Khan
2021-02-11 0:13 ` kernel test robot
2021-02-10 0:42 ` [PATCH 5/5] ath10k: reduce invalid ht params rate message noise Shuah Khan
2021-02-10 2:36 ` Wen Gong
2021-02-10 8:28 ` Kalle Valo [this message]
2021-02-10 16:13 ` Shuah Khan
2021-02-11 11:24 ` Kalle Valo
2021-02-26 18:01 ` Shuah Khan
2023-09-20 18:27 ` James Prestwood
2023-09-20 19:23 ` Jeff Johnson
2023-11-14 19:31 ` James Prestwood
2023-11-14 20:57 ` Jeff Johnson
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=87h7mktjgi.fsf@codeaurora.org \
--to=kvalo@codeaurora.org \
--cc=ath10k@lists.infradead.org \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=wgong@codeaurora.org \
/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;
as well as URLs for NNTP newsgroup(s).