On 4/18/2023 5:34 PM, Johannes Berg wrote:
On Tue, 2023-04-18 at 17:27 +0800, Wen Gong wrote:
Now lower driver I used do not store the key
Sure, that's fine.
and do not trigger
BSS_CHANGED_ASSOC for new links after assoc.
I think you need to think hard about this ... whatever BSS_CHANGED_ASSOC
causes is likely no longer correct in MLO. Again, the assoc state
*itself* is only changed once, when the whole MLD associated.
So my suggestion is a way to active all links while assoc, this way is
simple for lower driver I used.
Sure, and we do that.
But that's not what you're asking - you're asking to re-do some *MLD*
state when a new link is added, and I'm saying that it doesn't make
sense to "add" (again) a key to the MLD that was already added, nor
calling a vif (MLD!) level method saying the MLD changed state to
associated (again).
I really think you should solve this in the driver, that doesn't mean
you have to _store_ he key, you can use one of the iteration functions
as well.
Also ieee80211_set_active_links() is another way to active all links
after assoc.
Sure.
May I add a new ops in struct ieee80211_ops? like this:
u16 active_links(struct ieee80211_hw *hw, struct ieee80211_vif vif, u16
new_links)"
then ieee80211_set_vif_links_bitmaps() call the ops to get the links for
station and set the sdata->vif.active_links with the return value from
lower driver,
it means lower driver will dynamic select the links count at this moment.
If lower driver not register ops active_links, then keep current logic.
johannes
