[PATCH 1/3] wifi: mac80211: add support to allow driver to generate local link address for station

[Wen Gong]

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@quicinc.com/
>>
>>>
>>>> +		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