Hello,
I'm interested in getting access to ieee80211_conn_settings
struct in drivers. Specifically, so I can deal with disabling
160Mhz in mt76 even if peer is 160Mhz for instance, on a per-station vdev basis.
Is this of general interest, and if so, any suggestions for you
you'd like to see it implemented?
Maybe put a copy of that struct into ieee80211_link_sta struct
during association so that the driver can find it?
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 3/23/24 11:55, Ben Greear wrote:
> Hello,
>
> I'm interested in getting access to ieee80211_conn_settings
> struct in drivers. Specifically, so I can deal with disabling
> 160Mhz in mt76 even if peer is 160Mhz for instance, on a per-station vdev basis.
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.
Looks like maybe Johannes' existing changes already make it a lot
easier to limit bandwidth in the association path...
Thanks,
Ben
>
> Is this of general interest, and if so, any suggestions for you
> you'd like to see it implemented?
>
> Maybe put a copy of that struct into ieee80211_link_sta struct
> during association so that the driver can find it?
>
> Thanks,
> Ben
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
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
On 3/25/24 02:47, Johannes Berg wrote:
> 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?
From what I can tell, mt76 figures out to disable ofdma or similar
by looking at beacon IEs. That is painful, but I guess it works.
But I want similar ability to tweak STA side connections without
resorting to debugfs or module param hacks.
>
>
>> 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 :)
Ok, I'll keep it my private hacks. I at least got it to compile copying
the conn_settings. I'll get everything rebased and make sure it works.
To actually make it all work one needs to add a way to
send new flags down through netlink...I figure that part would face resistance
as well...
Thanks,
Ben
>
> johannes
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com