Received-SPF: pass (google.com: domain of linux-wireless+bounces-2805-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: <7e342de34398b844226ea53851cd2b081d8131ce.camel@sipsolutions.net>
Subject: Re: [PATCH v5 2/3] wifi: mac80211: add support for AP channel
 switch with MLO
From: Johannes Berg <johannes@sipsolutions.net>
To: Aditya Kumar Singh <quic_adisi@quicinc.com>
Cc: linux-wireless@vger.kernel.org
Date: Tue, 30 Jan 2024 11:51:23 +0100
In-Reply-To: <033151e5-7857-4c44-9b12-d8d8317a4139@quicinc.com>
References: <20240125130410.827701-1-quic_adisi@quicinc.com>
	 <20240125130410.827701-3-quic_adisi@quicinc.com>
	 <d4e77541479560147d453b7b5c06de3f940bad35.camel@sipsolutions.net>
	 <033151e5-7857-4c44-9b12-d8d8317a4139@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.3 (3.50.3-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

On Sat, 2024-01-27 at 10:28 +0530, Aditya Kumar Singh wrote:
> >=20
> > Hm. I'm going to send some patches soon that remove the puncturing stuf=
f
> > and move it into the chandef (as we discussed elsewhere), but just
> > noting that - doesn't need to concern you here, I think.
> >=20
>=20
> Oh okay! Let's see if at all it conflicts, will send a re-based once=20
> those gets merged.

I did send my patches now, so you're very much welcome to take a look at
all that I've posted (and provide comments, I'd appreciate it!), but
*please* don't rebase right now or anything, was just noting this in
passing.

If we're happy with both sets of patches surely I can also deal with the
conflicts, that will not be hard.

> > > +	if (cfg80211_chandef_identical(&params->chandef, &link_conf->chande=
f))
> > >   		return -EINVAL;
> >=20
> > Also another thing unrelated to your patch - I'm thinking about removin=
g
> > that identical() check entirely - you might want to switch to the same
> > channel with quiet=3D1. At least for testing that'd be really useful, a=
nd
> > I don't think it really serves any purpose to forbid it.
> >=20
> Yeah, we can do. But is there any actual use case? Also, what if some=20
> notorious user space application simply sends NL command without even=20
> quiet=3D1? There should be some check I guess?

I did post that patch too, and we're probably better off discussing it
there, but ... I'm not sure we care much about a broken userspace
application running with root privileges breaking something here? :-)

And at least for testing it's very useful to be able to do that. Agree
that identical channel and quiet=3D=3D0 doesn't make _sense_, but even then
I'm not sure there's a lot of value in not permitting it. With quiet=3D=3D1
at least it does make some sense still though, and we're currently not
allowing it, hence my patch (to be able to test scenarios like that we
saw elsewhere.)

Anyway, again, don't bother about rebase or anything!

johannes