[PATCH 5/5] ath10k: reduce invalid ht params rate message noise

[James Prestwood]

On 9/20/23 12:23 PM, Jeff Johnson wrote:
> (just a resend with Wen's current e-mail address, no further comments)
> On 9/20/2023 11:27 AM, James Prestwood wrote:
>> On 2/26/21 10:01 AM, Shuah Khan wrote:
>>> On 2/11/21 4:24 AM, Kalle Valo wrote:
>>>> Shuah Khan <skhan at linuxfoundation.org> writes:
>>>>
>>>>> On 2/10/21 1:28 AM, Kalle Valo wrote:
>>>>>> Wen Gong <wgong at 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 at 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. :)
>>>>
>>>> I would rather first try to fix the root cause, which is the firmware
>>>> sending invalid rates. Wen, you mentioned there's a fix in 
>>>> firmware. Do
>>>> you know which firmware version (and branch) has the fix?
>>>>
>>>
>>> Picking this back up. Wen, which firmware version has this fix? I can
>>> test this on my system and get rid of the noisy messages. :)
>>>
>>> thanks,
>>> -- Shuah
>>
>> I know its been years, but reading through this Wen mentioned there 
>> is a fix in the firmware? I haven't tried all of the firmware 
>> binaries in Kalle's tree but the most recent definitely still spam 
>> the logs with this message. Is there a specific version I can use to 
>> get rid of these?
>>
>> One thing to note is the older "firmware-4.bin" did not have this 
>> problem, but was met with worse problems like driver/firmware crashes.

I hate to keep bringing this up, and if its a "won't fix" type of issue 
you don't have to tell me twice and I can deal with it out of tree. Any 
answer would be greatly appreciated so I know how to proceed, and if its 
something I can wait for on upstream or handle on my own. Since its 
apparently a firmware bug its not something I can fix, or I would try to 
myself.

(sorry, my last inquiry was mistakenly from a different email address).

Thanks,

James