wifi: mt76: mt7915: remove VHT160 capability on MT7915?

[Thomas Walker]

(Apologies Felix, as you're probably getting this twice because I'm an
idiot and didn't set gmail to plain text.)

Hi all,

I've been running the openwrt-23.05 branch on a Redmi AX6S (RB01) for
maybe 6 months now without issue.  I build my own to include custom
config, etc and usually update every week or so.  But I've been out of
town for a month and didn't update while I was away.  When I did
update a few days ago, my 5G wifi failed to come up with:

Sat Aug 19 17:42:09 2023 daemon.notice hostapd: wl1-ap0: interface
state HT_SCAN->DFS
Sat Aug 19 17:42:09 2023 daemon.notice hostapd: wl1-ap0: DFS-CAC-START
freq=5180 chan=36 sec_chan=1, width=2, seg0=50, seg1=0, cac_time=60s
Sat Aug 19 17:42:09 2023 daemon.err hostapd: DFS start_dfs_cac() failed, -1
Sat Aug 19 17:42:09 2023 daemon.notice hostapd: wl1-ap0: interface
state DFS->DISABLED

Granted, the output before wasn't exactly pretty, but it worked (I
presume the warnings are because these aren't DFS channels, but...):

Sat Aug 19 17:42:09 2023 daemon.notice hostapd: wl1-ap0: interface
state HT_SCAN->DFS
Sat Aug 19 17:42:09 2023 daemon.notice hostapd: wl1-ap0: DFS-CAC-START
freq=5180 chan=36 sec_chan=1, width=2, seg0=50, seg1=0, cac_time=60s
Sat Aug 19 17:52:01 2023 daemon.notice hostapd: wl1-ap0:
DFS-CAC-COMPLETED success=1 freq=5180 ht_enabled=0 chan_offset=0
chan_width=5 cf1=5250 cf2=0
Sat Aug 19 17:52:01 2023 daemon.warn hostapd: Can't set DFS state for
freq 5180 MHz
Sat Aug 19 17:52:01 2023 daemon.warn hostapd: Can't set DFS state for
freq 5200 MHz
Sat Aug 19 17:52:01 2023 daemon.warn hostapd: Can't set DFS state for
freq 5220 MHz
Sat Aug 19 17:52:01 2023 daemon.warn hostapd: Can't set DFS state for
freq 5240 MHz
Sat Aug 19 17:52:02 2023 daemon.notice hostapd: wl1-ap0: interface
state DFS->ENABLED

I spent a bit of time bisecting the issue and it came down to:

commit 063641f8cf7990731919b950c1bf9eb15d1e74c9
Author: Felix Fietkau <nbd at nbd.name>
Date:   Fri Jul 14 11:20:30 2023 +0200

    mt76: update to the latest version

    bb3937d5c3e0 wifi: mt76: mt7915: remove VHT160 capability on MT7915

    Signed-off-by: Felix Fietkau <nbd at nbd.name>

Which corresponds to (in https://github.com/openwrt/mt76):

commit bb3937d5c3e0b13c0d08747ec0fc9726fb4fd870
Author: Felix Fietkau <nbd at nbd.name>
Date:   Fri Jul 14 10:57:15 2023 +0200

    wifi: mt76: mt7915: remove VHT160 capability on MT7915

    The IEEE80211_VHT_CAP_EXT_NSS_BW value already indicates support
for half-NSS
    160 MHz support, so it is wrong to also advertise full 160 MHz support.

    Fixes: c2f73eacee3b ("wifi: mt76: mt7915: add back 160MHz channel
width support for MT7915")
    Signed-off-by: Felix Fietkau <nbd at nbd.name>

Yes, I've been (up until now) successfully using VHT160 on channel 36
as it is the only reliable 160mhz band available in the US that isn't
subject to DFS (and where I'm located, DFS strikes are almost
constant).  Reverting this patch (or choosing VHT80 or lower) does
indeed work.  I must admit, I'm not well versed in various wireless
extensions or what 'IEEE80211_VHT_CAP_EXT_NSS_BW' or 'half-NSS'
entails (I do kernel stuff for a living, but datacenter stuff, so my
wireless knowledge is very limited), but clearly something broke for
me here.  Relevant radio section is below:

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11a'
        option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option cell_density '0'
        # best channel for our locality (104 keeps getting DFS strikes)
        option channel '36'
        # the two ranges that support 160mhz
        # 149-177 should, but is missing channels in regdb and turns into 80mhz
        # https://forum.openwrt.org/t/5-ghz-wlan-craps-out-upon-radar-detection-start-dfs-cac-failed/71018/15
        # in practice, this means we always stay at 36 (no DFS).  But
so does everyone else.
        option channels '36-64 100-128'
        option country 'US'
        option htmode 'VHT160'

(the 149-177 regdb comment is likely dated, but I haven't tried it
again in recent history)

Is there something that I'm missing here that would allow VHT160 to
work with this patch?

Thank you very much!
(I've been an openwrt user for nearly a decade now and am so happy
that there is a reliable, stable alternative to the crap OEM
firmware... Keep up the great work!)