Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <7199bd7d-b45c-5c72-576e-363ad37cce82@quicinc.com>
Date:   Mon, 12 Sep 2022 18:55:04 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Subject: Re: [PATCH] wifi: mac80211: RCU-ify link STA pointers
Content-Language: en-US
To:     Kalle Valo <kvalo@kernel.org>
CC:     Johannes Berg <johannes@sipsolutions.net>,
        linux-wireless <linux-wireless@vger.kernel.org>,
        <ath11k@lists.infradead.org>
References: <24df3a0c-a312-d9b6-5840-1eacd79d824b@quicinc.com>
 <87a67498b4.fsf@kernel.org>
From:   Wen Gong <quic_wgong@quicinc.com>
In-Reply-To: <87a67498b4.fsf@kernel.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 9/12/2022 6:49 PM, Kalle Valo wrote:
> Wen Gong <quic_wgong@quicinc.com> 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.