Hi Johannes,
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.
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);
commit:c71420db653aba30a234d1e4cf86dde376e604fa
wifi: mac80211: RCU-ify link STA pointers
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index c58d9689f51f..7947e9a162a9 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -37,7 +37,7 @@ void rate_control_rate_init(struct sta_info *sta)
struct ieee80211_supported_band *sband;
struct ieee80211_chanctx_conf *chanctx_conf;
- ieee80211_sta_set_rx_nss(sta, 0);
+ ieee80211_sta_set_rx_nss(&sta->deflink);
if (!ref)
return;
Wen Gong <[email protected]> writes:
> Hi Johannes,
>
> 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.
> 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);
>
> commit:c71420db653aba30a234d1e4cf86dde376e604fa
> wifi: mac80211: RCU-ify link STA pointers
Strange format and s-o-b missing. Was this meant as an RFC patch?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On 9/12/2022 6:49 PM, Kalle Valo wrote:
> Wen Gong <[email protected]> writes:
>
>> Hi Johannes,
>>
>> 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.
>> 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);
>>
>> commit:c71420db653aba30a234d1e4cf86dde376e604fa
>> wifi: mac80211: RCU-ify link STA pointers
> Strange format and s-o-b missing. Was this meant as an RFC patch?
This is not a patch for review, it is to ask some question about the patch
"wifi: mac80211: RCU-ify link STA pointers" which is already upstream.
Wen Gong <[email protected]> writes:
> On 9/12/2022 6:49 PM, Kalle Valo wrote:
>> Wen Gong <[email protected]> writes:
>>
>>> Hi Johannes,
>>>
>>> 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.
>>> 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);
>>>
>>> commit:c71420db653aba30a234d1e4cf86dde376e604fa
>>> wifi: mac80211: RCU-ify link STA pointers
>> Strange format and s-o-b missing. Was this meant as an RFC patch?
>
> This is not a patch for review, it is to ask some question about the patch
>
> "wifi: mac80211: RCU-ify link STA pointers" which is already upstream.
Then you should not add "[PATCH]" in the subject. The string "[PATCH]"
is supposed to inform that the email contains a patch which should be
applied.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Please ignore this mail which is not really for patch review.
On 9/12/2022 7:05 PM, Kalle Valo wrote:
> Wen Gong <[email protected]> writes:
>
>> On 9/12/2022 6:49 PM, Kalle Valo wrote:
>>> Wen Gong <[email protected]> writes:
>>>
>>>> Hi Johannes,
>>>>
>>>> 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.
>>>> 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);
>>>>
>>>> commit:c71420db653aba30a234d1e4cf86dde376e604fa
>>>> wifi: mac80211: RCU-ify link STA pointers
>>> Strange format and s-o-b missing. Was this meant as an RFC patch?
>> This is not a patch for review, it is to ask some question about the patch
>>
>> "wifi: mac80211: RCU-ify link STA pointers" which is already upstream.
> Then you should not add "[PATCH]" in the subject. The string "[PATCH]"
> is supposed to inform that the email contains a patch which should be
> applied.
>