Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Message-ID: <af4a763b624363543a37140c2106fb7a05800977.camel@sipsolutions.net>
Subject: Re: [PATCH v2 1/2] wifi: cfg80211/mac80211: add support for AP
 channel switch with MLO
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Aditya Kumar Singh <quic_adisi@quicinc.com>,
        linux-wireless@vger.kernel.org
Date:   Mon, 25 Sep 2023 15:10:46 +0200
In-Reply-To: <20230925115822.12131-2-quic_adisi@quicinc.com>
References: <20230925115822.12131-1-quic_adisi@quicinc.com>
         <20230925115822.12131-2-quic_adisi@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 Mon, 2023-09-25 at 17:28 +0530, Aditya Kumar Singh wrote:
> Currently, during channel switch, deflink (or link_id 0) is always
> considered. However, with Multi-Link Operation (MLO), there is a
> need to handle link specific data structures based on the actual
> operational link_id during channel switch operation.
>=20
> Hence, add support for the same. Non-MLO based operations will use
> link_id as 0 or deflink member as applicable.

Much of this commit log really applies to mac80211 - perhaps make a
simple cfg80211 patch first only?


> +	link_data =3D sdata_dereference(sdata->link[link_id], sdata);

We should probably use wiphy_dereference() now?

Perhaps we should just get rid of sdata_dereference() entirely, after
all, it's the same now, just the arguments are switched for no good
reason.

> -	conf =3D rcu_dereference_protected(sdata->vif.bss_conf.chanctx_conf,
> +	conf =3D rcu_dereference_protected(link_conf->chanctx_conf,
>  					 lockdep_is_held(&local->hw.wiphy->mtx));

Hm, I guess that was an artifact of the (mechanical) conversions - but
really that should probably be wiphy_dereference() as well now?

johannes