Re: [PATCH wireless] wifi: mac80211: use HT CCFS2 when computing the AP's HE and lower bandwidth

[John Macias <dencity7@gmail.com>]

On Mon, 2026-10-26 at 12:07 +0100, Johannes Berg wrote:
> This, by itself, is wrong.

Thanks. I think I see why: CCFS2 only applies to a STA that can
interpret Extended NSS BW, and my patch applied it to every station.
Please drop it.

I looked further and may have found the actual cause, but I'm not
certain. Below I've separated what I measured from what I concluded
by reading code. Corrections are very welcome.

Setup: IPQ8074 (Netgear RAX120v1), ath11k, firmware
WLAN.HK.2.0-01792, HE160 BSS on channel 36. Clients: MT7925 and AX200.

What I measured:

- Before any change, "iw phy" on the AP reports VHT Capabilities
  0x738f09fa, prints the Supported Channel Width as "(reserved)", and
  shows "VHT extended NSS: not supported".

- In the beacon I captured for the original patch, the VHT Operation
  element has Channel Width 1 and CCFS1 0, and the 160 MHz centre is
  in the HT Operation CCFS2 field.

- Both clients report a 160 MHz link. On the AP side the peers were
  set up as 11ax-he80 and the AP's transmit rate to them stayed at
  80 MHz (MT7925 download about 810 Mb/s).

- With the change described below, "iw phy" prints "160 MHz, 80+80
  MHz" and still "VHT extended NSS: not supported". The AP then
  transmits to both clients at 160 MHz HE-MCS 11, with unmodified
  mac80211 and without my earlier patch.

What I concluded from the code, without confirming every step on the
device:

1. My reading of 0x738f09fa is Supported Channel Width Set 2 with
   Extended NSS BW Support 1. As I read Table 9-272, that combination
   isn't defined, which would fit iw printing "reserved".
   ath11k_create_vht_cap() copies the firmware's value unchanged.

2. ath11k sets SUPPORTS_VHT_EXT_NSS_BW and
   IEEE80211_VHT_EXT_NSS_BW_CAPABLE only when the firmware reports an
   NSS ratio. "extended NSS: not supported" suggests this firmware
   doesn't. I didn't print nss_ratio_enabled itself.

3. hostapd_eid_vht_operation() moves the 160 MHz centre to CCFS2 when
   the driver's capabilities include Extended NSS BW Support. That
   would explain the beacon above. I didn't capture a beacon after the
   change, so I'm assuming it now uses CCFS1 because the AP transmits
   at 160 MHz.

4. ieee80211_calc_ap_he_and_lower() reads only CCFS1, so the AP limits
   every station to 80 MHz. Since the hardware doesn't claim extended
   NSS support, this looks correct to me, and my patch was the wrong
   fix.

The change I tested clears IEEE80211_VHT_CAP_EXT_NSS_BW_MASK in
ath11k_create_vht_cap() when the firmware gives no NSS ratio.

Questions where I may still be wrong:

- Is ath11k the right place for this? Or should mac80211 or hostapd
  ignore Extended NSS BW Support in the capabilities when the driver
  doesn't set SUPPORTS_VHT_EXT_NSS_BW?

- I also tried applying CCFS2 per station (only for STAs that set
  Extended NSS BW Capable). On this hardware it changed nothing: both
  clients stayed at 80 MHz. As far as I can tell, that's because
  mac80211 clears that bit for every station when the driver lacks
  SUPPORTS_VHT_EXT_NSS_BW. On hardware that does support it, an AP
  that signals 160 MHz through CCFS2 would still be limited to 80 MHz
  by ieee80211_calc_ap_he_and_lower(). Is that expected, or is it
  handled somewhere I missed?

If the ath11k change looks right to you, I'll send it to the ath11k
list. I can also capture the beacon after the change, or print the
firmware's NSS ratio, if that would help.

John