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
