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: <cd762f33b1c15566237c85f1e265ee8a00006f5c.camel@sipsolutions.net>
Subject: Re: [PATCH 1/3] wifi: mac80211: add support to allow driver to
 generate local link address for station
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Wen Gong <quic_wgong@quicinc.com>, ath12k@lists.infradead.org
Cc:     linux-wireless@vger.kernel.org
Date:   Wed, 13 Sep 2023 10:55:00 +0200
In-Reply-To: <20230906103458.24092-2-quic_wgong@quicinc.com>
References: <20230906103458.24092-1-quic_wgong@quicinc.com>
         <20230906103458.24092-2-quic_wgong@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

On Wed, 2023-09-06 at 06:34 -0400, Wen Gong wrote:
> Currently the local link address of all links is random generated by
> eth_random_addr() in mac80211 while connecting to a MLO AP for station
> mode. The MAC address of link is not passed from NL command. The 1st
> link address is generated while authenticate with AP, the other links'
> addresses are generated after assoc success with AP.
>=20
> It is not convenient for some driver, reason is, for station mode,
> the interface with its mac address is already created in driver after
> wlan load, it is used for hw scan and non-MLO connection.
>=20
> When connecting to MLO AP, driver reuse the interface as the 1st link of
> MLO. If the mac address of the 1st link changed to a new value, then
> driver need to change the mac address and do many synchronous operation
> with firmware. Thus the operation become complex. After MLO disconnect,
> driver need to restore the old mac address, it is also another complex
> operation.
>=20
> The hw scan maybe happen through the MLO connection/disconnection. And
> the hw scan uses the 1st link address while MLO connected and uses the
> interface address while MLO is disconnected, this leads hw scan complex.
>=20
> Hence add this interface to allow driver to generate the address of each
> link while MLO connection. Then driver could provide the same mac address
> for the 1st link, thus hw scan/NON-MLO connection/1st link of MLO will us=
e
> the same mac address, then operation become easy.

Maybe after all this explanation, all we need is a flag "reuse MLD
address for assoc link"?


> +		ret =3D 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.

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?

johannes