wifi: mac80211: mlo rx nss value 0 of wifi

Wen Gong quic_wgong at quicinc.com
Mon Oct 17 01:12:56 PDT 2022


On 10/17/2022 4:02 PM, Johannes Berg wrote:
> On Mon, 2022-10-17 at 16:00 +0800, Wen Gong wrote:
>> On 10/17/2022 3:49 PM, Johannes Berg wrote:
>>> On Mon, 2022-10-17 at 09:48 +0200, Johannes Berg wrote:
>>>> Hi,
>>>>
>>>>>> Currently for MLO test, the others links's rx_nss of struct
>>>>>> ieee80211_link_sta is still value 0 in ieee80211_set_associated(),
>>>>>> becaue they are not pass into ieee80211_sta_set_rx_nss() in
>>>>>> mac80211 except the deflink which means the primary link in
>>>>>> rate_control_rate_init(). This lead driver get nss = 0 for
>>>>>> other links. Will you fix it or is it design by default?
>>>>>>
>>>>>> Only primary link has valid rx_nss value which is not 0 by below call
>>>>>> stack.
>>>>>> ieee80211_assoc_success()
>>>>>>       ->rate_control_rate_init(sta);
>>>>>>           ->ieee80211_sta_set_rx_nss(&sta->deflink);
>>>> Right, none of the rate scaling related stuff was updated yet.
>>>>
>>> Though for this case maybe we can just move ieee80211_sta_set_rx_nss()
>>> to some better place outside of rate_control_rate_init() and have it
>>> done with the right link, and also on changes?
>>>
>>> johannes
>> I did below change in my internal test, and not found the NSS=0 issue
>> again for 2 link MLO.
>>
>> wifi: mac80211: update all links rx nss by ieee80211_sta_set_rx_nss() in
>> ieee80211_assoc_success()
>>
> I guess valid links wasn't set at that point yet?
>
> Anyway should also move out of rate_control_rate_init() and probably
> into something like ieee80211_assoc_config_link()? That already does
> some rx_nss calculations which is probably not great ...

OK. I will test with my change internal now. And replace to use upstream 
change

after someone fix it.

> johannes



More information about the ath11k mailing list