Received-SPF: pass (google.com: domain of linux-wireless+bounces-5172-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <661c532c30e9fa218cf0b3d30da0bb65aafc4e8c.camel@sipsolutions.net>
Subject: Re: Access to ieee80211_conn_settings in the driver?
From: Johannes Berg <johannes@sipsolutions.net>
To: Ben Greear <greearb@candelatech.com>, "linux-wireless@vger.kernel.org"
	 <linux-wireless@vger.kernel.org>
Date: Mon, 25 Mar 2024 10:47:10 +0100
In-Reply-To: <1df701f9-3f27-4887-a9ed-60cf2f12beb4@candelatech.com>
References: <1df701f9-3f27-4887-a9ed-60cf2f12beb4@candelatech.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

Hi Ben

> I'm interested in getting access to ieee80211_conn_settings
> struct in drivers.

My first instinct here is to say no. This thing was only introduced
recently, and it was ... difficult ... to do. I don't even want to
imagine I'd have had to worry about a whole bunch of drivers using it
for random purposes as well.

> Specifically, so I can deal with disabling
> 160Mhz in mt76 even if peer is 160Mhz for instance, on a per-station vdev=
 basis.

Not sure how that even makes sense? You have the min_def in the chandef
though, so you could do some bandwidth tricks there for AP side?

> Actually, 160Mhz is bad example, but in case I want to pass other
> association config info into the driver, like disabling as much of
> OFDMA or MU-MIMO as possible.

No idea what that means ... I mean I guess we could add somewhere
(bss_conf?) a flag indicating "things" are needed, e.g. if you're
connecting 160 MHz is it VHT or HE or EHT, to set things accordingly?


> Is this of general interest, and if so, any suggestions for you
> you'd like to see it implemented?

I'd like to _not_ see it implemented :)

johannes