Received-SPF: pass (google.com: domain of linux-wireless+bounces-7477-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <88b36efce036ad4f0316ffb434a5352bbe4f1599.camel@sipsolutions.net>
Subject: Re: [PATCH] wifi: mac80211: move radar detect work to sdata
From: Johannes Berg <johannes@sipsolutions.net>
To: Aditya Kumar Singh <quic_adisi@quicinc.com>, 
	linux-wireless@vger.kernel.org
Cc: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Date: Fri, 10 May 2024 16:27:58 +0200
In-Reply-To: <4dd39edb-cd23-482a-8c94-b09142d92198@quicinc.com>
References: 
	<20240506211311.43bd82c6da04.Ib39bec3aa198d137385f081e7e1910dcbde3aa1b@changeid>
	 <4dd39edb-cd23-482a-8c94-b09142d92198@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

On Thu, 2024-05-09 at 09:52 +0530, Aditya Kumar Singh wrote:
> On 5/7/24 00:43, Johannes Berg wrote:
> > At some point we thought perhaps this could be per link, but
> > really that didn't happen, and it's confusing. Radar detection
> > still uses the deflink to allocate the channel, but the work
> > need not be there. Move it back.
>=20
> I'm currently working on MLO DFS support. It is better if the work can=
=20
> be left in per link structure. With proper support, instead of deflink=
=20
> it will use appropriate link.

A number of patches I have actually depend on this (though only by
patch, not semantically), so it might be better to leave it and just
move it back.

In any case, your work will likely have (simple) conflicts in some
places with the other patches I posted.

But we have a couple of weeks to decide, I guess, given the release is
around the corner.

johannes