Re: [PATCH RFC wireless-next] wifi: mac80211_hwsim: dont perform rate validation for S1G

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2025-10-08 at 12:40 +1100, Lachlan Hodges wrote:
> mac80211 does not support TX/RX rate reporting for S1G bandwidths and
> as a result WARNs occur during validation as the default value of 20MHz
> (0) is always higher then the highest S1G bandwidth of 16MHz. This
> prevents association from occuring in some instances.
> 
> Skip bandwidth validation for S1G interfaces to avoid spurious WARNs and
> ensure a clean association process as there is no support for S1G TX/RX
> bandwidths.
> 
> Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
> ---
> This is kind of a bandaid fix (hence why RFC), but implementing proper
> native rate control support for S1G within minstrel and mac80211 is not
> pretty (lack of flag space, ordering of RX bandwidth enum, aliasing with
> VHT flags and a myriad of other issues).

Yeah that makes sense. It might be more feasible with the table-based
approach (sta_rate_tbl_update), but there's not a lot of sense in adding
support for S1G to minstrel (or adding another algorithm) when no driver
would ever use it.

And a lot of the issues would still remain for feedback etc.

> If an S1G driver is submitted it
> would be considered a "modern" driver and would probably contain its own
> rate control. There has been some S1G hostap work recently submitted [1]
> though it's only STA side though this will need to be fixed in order for
> proper tests to be run.

I'm not sure really to be considered "modern" you need driver/firmware
rate control, but I'd assume a new driver were to do that anyway :)

So overall it seems reasonable to mostly ignore the rate control issue,
but maybe it'd make more sense to be "cleaner" about it, maybe
separating out something like HAS_RATE_CONTROL to be per station, i.e.
letting drivers somehow (not) set WLAN_STA_RATE_CONTROL?

And removing the checks here in tx() seems a bit odd, why should that
even be necessary? Surely _something_ would still need to be done here,
even if only to generate some sensible radiotap headers for the virtual
sniffer interface?

johannes