On 9/26/2023 5:45 PM, Johannes Berg wrote:
On Fri, 2023-09-15 at 16:11 +0800, Wen Gong wrote:
On 9/13/2023 4:55 PM, Johannes Berg wrote:
On Wed, 2023-09-06 at 06:34 -0400, Wen Gong wrote:
[...]
Maybe after all this explanation, all we need is a flag "reuse MLD
address for assoc link"?
yes. It is similar as I said before here:
https://lore.kernel.org/linux-wireless/b9c6d022-12c3-a696-c4b9-cb14a6d30a45@xxxxxxxxxxx/
+ ret = drv_generate_link_addr(sdata->local, sdata,
+ link_id, link->conf->addr);
+ if (ret)
+ eth_random_addr(link->conf->addr);
should probably refactor this into a separate function though.
OK.
I'm also not sure how the driver even knows that a link it's being asked
to get the address for *is* the assoc link? Do you want to rely on that
being the first address handed out?
Current I used (vif->valid_links==0) check for assoc link. When
drv_generate_link_addr() called for the assoc link, vif->valid_links
is 0, and it is not 0 for other links.
That seems a bit questionable?
Also we can change to indicate a new flag(e.g.
IEEE80211_HW_MLO_FIXED_ASSOC_LINK_ADDR) to
mac80211 from driver, if the flag is not set, then keep current logic.
If it is set, then copy vif->addr to the link->conf->addr for assoc link
in ieee80211_mgd_setup_link().
The logic keep not change for other links.
Well then again, what do you want for AP mode? Anyway you can still
distinguish, and if we later need to change an internal API that's not
the end of the world either ...
I do not want any change for AP mode.
So OK, I guess we can live with this, just would like to see it wrapped
up into a single function.
johannes
