Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Message-ID: <7ac4b560-26d5-2125-b1be-2f1313097d0a@quicinc.com>
Date:   Tue, 26 Sep 2023 18:44:02 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: [PATCH 1/3] wifi: mac80211: add support to allow driver to
 generate local link address for station
Content-Language: en-US
To:     Johannes Berg <johannes@sipsolutions.net>,
        <ath12k@lists.infradead.org>
CC:     <linux-wireless@vger.kernel.org>
References: <20230906103458.24092-1-quic_wgong@quicinc.com>
 <20230906103458.24092-2-quic_wgong@quicinc.com>
 <cd762f33b1c15566237c85f1e265ee8a00006f5c.camel@sipsolutions.net>
 <d23b617e-5ca0-e721-0c2a-fcca8942efef@quicinc.com>
 <4dac29f3844309fb62afe6acd4c4ebd379b0a194.camel@sipsolutions.net>
From:   Wen Gong <quic_wgong@quicinc.com>
In-Reply-To: <4dac29f3844309fb62afe6acd4c4ebd379b0a194.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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