Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 5/5] ath10k: reduce invalid ht params rate message noise
To:     Kalle Valo <kvalo@codeaurora.org>, Wen Gong <wgong@codeaurora.org>
Cc:     netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
        linux-kernel@vger.kernel.org, ath10k@lists.infradead.org,
        kuba@kernel.org, davem@davemloft.net,
        Shuah Khan <skhan@linuxfoundation.org>
References: <cover.1612915444.git.skhan@linuxfoundation.org>
 <76a816d983e6c4d636311738396f97971b5523fb.1612915444.git.skhan@linuxfoundation.org>
 <5c31f6dadbcc3dcb19239ad2b6106773@codeaurora.org>
 <87h7mktjgi.fsf@codeaurora.org>
From:   Shuah Khan <skhan@linuxfoundation.org>
Message-ID: <db4cd172-6121-a0b7-6c3f-f95baae1c1ed@linuxfoundation.org>
Date:   Wed, 10 Feb 2021 09:13:07 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <87h7mktjgi.fsf@codeaurora.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2/10/21 1:28 AM, Kalle Valo wrote:
> 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?
> 

Here is the info:

ath10k_pci 0000:02:00.0: qca6174 hw3.2 target 0x05030000 chip_id 
0x00340aff sub 17aa:0827

ath10k_pci 0000:02:00.0: firmware ver WLAN.RM.4.4.1-00140-QCARMSWPZ-1 
api 6 features wowlan,ignore-otp,mfp crc32 29eb8ca1

ath10k_pci 0000:02:00.0: board_file api 2 bmi_id N/A crc32 4ac0889b

ath10k_pci 0000:02:00.0: htt-ver 3.60 wmi-op 4 htt-op 3 cal otp max-sta 
32 raw 0 hwcrypto 1

>> 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.
> 

Agreed.

> 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.
> 

Would it be helpful to adjust the default rate limits and set the to
a higher value instead. It might be difficult to account all possible
invalid values?

Something like, ath10k_warn_ratelimited() to adjust the

DEFAULT_RATELIMIT_INTERVAL and DEFAULT_RATELIMIT_BURST using
DEFINE_RATELIMIT_STATE

Let me know if you like this idea. I can send a patch in to do this.
I will hang on to this firmware version for a little but longer, so
we have a test case. :)

thanks,
-- Shuah