[PATCH] wifi: mac80211: fix assigning channel in activate links

[Aditya Kumar Singh]

On 10/1/24 13:38, Johannes Berg wrote:
> On Tue, 2024-10-01 at 13:07 +0530, Aditya Kumar Singh wrote:
>>
>> First iterate and do only _ieee80211_link_use_channel() this part. Then
>> let the flow as usual and after stations are added, do the
>> link_info_changed() part.
> 
> That would seem to make sense, it also matches assoc flow better.
> Although not sure that matters too much, since this is necessarily very
> different as it's while associated anyway.
> 
>>> But also this seems to break out driver for other reasons, because it
> 
> type - I meant "our driver"
> 
>>> initializes rate control somewhere here and needs a station for that.
>>> Didn't look deeply into that yet though.
>>
>> Okay so doing as I said above could work -
>>
>> if (add) {
>> 	...
>> }
>>
>> for_each_set_bit(link_id, &rem, ..) {
>> 	...
>> }
>>
>> for_each_set_bit(link_id, &add ...) {
>> 	_ieee80211_link_use_channel()
>> }
>>
>> list_for_each_entry(sta, &local->sta_list, list) {
>> 	...
>> }
>>
>> ...
>>
>> for_each_set_bit(link_id, &add ....) {
>> 	now call
>> 	ieee80211_mgd_set_link_qos_params()
>> 	ieee80211_link_info_change_notify()
>> }
>>
>> ...
>>
>>
>> At least I tried both of these ways in hwsim. I dont see any failures.
>> Hence I thought why not move whole for loop to top instead.
> 
> Right, I don't know - I guess I should try with our driver?
> 

Yes please that would be of great help. Let me send a next version 
having the changes as discussed above and then you could pick that for 
testing and let us know whether it is working as expected by Intel driver?

It would be better if other MLO based drivers could also test this? I 
mean if possible they could also test and let us know if this breaks any 
of their expectations! Or if not test, at least ack this change?


-- 
Aditya