wifi: rtw89: advertise WFA-certified EHT capabilities for 8922a

This series advances rtw89 EHT capability advertisement to match what Realtek's own RTL8922AE silicon is certified for by the Wi-Fi Alliance in WFA Cert WFA129313 (RTL8922AE 802.11be and Bluetooth combo module, 2024-05-23, FW 6102.24.109.0,
https://api.cert.wi-fi.org/api/certificate/download/public?variantId=129706).

The cert lists EMLSR, STR, Multi-RU, MCS 8-13, DL/UL MU-MIMO, UL OFDMA, SU-MIMO, beamforming sounding, multi-link reconfiguration, advertised TID-to-link mapping, BSS critical update, A-MPDU with A-MSDU, LDPC, operating mode indication, EPCS priority access, and several other features as certified for this chip. The driver currently advertises some of these and hard-zeroes others. This series fills the gap for four cap surfaces:

Patch 1/4: EML Capabilities (EMLSR_SUPP + padding/transition delays)
plus Restricted TWT (EHT MAC Cap0). EMLSR is explicitly listed in the WFA cert. R-TWT is silicon-supported per the chip's documented EHT MAC capabilities.
Patch 2/4: Multi-RU OFDMA receive cap (CAP5_RX_LESS_242_TONE_RU_SUPP).
Multi-RU is verbatim in the WFA cert.
Patch 3/4: MLD operation caps — TID-to-link mapping (SAME) +
Link Reconfiguration support. Both verbatim in the WFA cert. Uses FIELD_PREP_CONST() (already used in this driver at usb.c:784-787) and matches the bit pattern Intel uses for its Wi-Fi 7 STAs (IWL_MVM_MLD_CAPA_OPS in iwlwifi/mvm/mac80211.c). MAX_SIMUL_LINKS is left at 0 (= 1 max simul link) consistent with the EMLSR-only operating mode the driver implements.
Patch 4/4: EHT OM Control (MAC Cap0). "Operating mode indication" is
verbatim in the WFA cert; mt7925 + iwlwifi mvm + hwsim precedent.

Industry context: this series advances rtw89 along the same axis every in-tree Linux WiFi 7 driver currently occupies — MLSR/EMLSR fast-switch on a single physical radio. True STR multi-radio aggregation is not implemented by any in-tree driver as of v6.15+ (iwlwifi, mt7925, ath12k, rtw89). The only known shipping consumer STR adapter on any OS is the Ubiquiti UniFi AirWire (closed firmware, UniFi-AP-only). This series does not attempt STR; it brings rtw89 EMLSR negotiation in line with the other three drivers.

Testing: applied as a stack to the morrownr/rtw89 OOT clone on Linux 6.19.11 (Bazzite F44) running RTL8922AU USB; tested against TP-Link Deco BE63 mesh (5-node) for 48h+ continuous association. Verified caps appear in iw phy output (Restricted TWT, OM Control, "Rx 1024-QAM And 4096-QAM < 242-tone RU"). active_links = 0x4 confirms expected EMLSR mode. wifi-health-check sweep (11 checks: wpa override, rpm-ostree state, rtw89 build, SELinux, NM dispatchers, regdomain, link state, SELinux AVC rate, MLO link count) passes 11/11 throughout the soak.

A/B comparison patched vs unpatched, 3-NIC concurrent reverse-mode iperf3, 5 reps patched + 3 reps unpatched per SSID, signal -10 to -25 dBm: no measurable throughput delta (MLO patched mean 1128 Mbps vs unpatched mean 1174 Mbps; 6 GHz patched mean 1099 Mbps vs unpatched mean 1169 Mbps; deltas well within ±5% noise floor and dominated by per-test MCS variation, not patch state). The patches enable correct cap advertisement matching what RTL8922A silicon supports per the WFA cert; they do not aim to deliver throughput improvement in steady-state operation against this AP. Patches are about correctness and standards-compliance, not throughput.

Tested only on RTL8922AU (USB variant); rtw89_init_eht_cap() and the iftype-ext-cap struct are shared across the rtw89 chip family. Non-AU variant testing from anyone with rtw89-supported hardware is welcome.

Note on EMLMR (EML Cap bit 7): the WFA cert does NOT list EMLMR for this chip. RTL8922A has rf_path_num=2 (single 2T2R RF block shared across bands), and the driver has no EMLMR enum, firmware H2C path, or PHY register block. EMLSR is the architectural ceiling for this silicon; this series does not advertise EMLMR.

Note on follow-up: a separate audit identified five further capability fields hard-zeroed in rtw89_init_eht_cap() (EHT A-MPDU exponent, partial-BW DL/UL MU-MIMO, MCS 14-15, sounding dimensions, 1024/4096-QAM wider-BW DL-OFDMA). Some of these are likely silicon ceilings (MCS 14-15 is consistent with the cert topping out at MCS 12-13); others may be driver-only gaps. I plan to send a small ASK email separately covering those questions before any follow-up patch series.

Louis Kotze (4):
wifi: rtw89: advertise EML Capabilities and Restricted TWT for 8922a
wifi: rtw89: advertise Multi-RU OFDMA receive for 8922a per WFA cert
wifi: rtw89: advertise MLD TID-to-link mapping and link reconfiguration
wifi: rtw89: advertise EHT OM Control for 8922a per WFA cert

 drivers/net/wireless/realtek/rtw89/core.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

Louis Kotze (4):
wifi: rtw89: advertise EML Capabilities and Restricted TWT for 8922a
wifi: rtw89: advertise Multi-RU OFDMA receive for 8922a per WFA cert
wifi: rtw89: advertise MLD TID-to-link mapping and link
reconfiguration
wifi: rtw89: advertise EHT OM Control for 8922a per WFA cert

 drivers/net/wireless/realtek/rtw89/core.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

base-commit: 7baf5857e15d722776898510a10546d6b2f18645

2.54.0

Wi-Fi Alliance Certificate WFA129313 (RTL8922AE 802.11be and Bluetooth combo module, 2024-05-23, FW 6102.24.109.0) certifies EMLSR (Enhanced Multilink Single-Radio) and STR (Simultaneous Transmit and Receive) for this chip. The driver currently sets eml_capabilities = 0 and mld_capa_and_ops = 0 in the Station iftype-ext-cap, which prevents the AP from negotiating EMLSR mode with this STA — multi-link association either falls back to MLSR (single-link) or fails entirely.

Populate eml_capabilities with IEEE80211_EML_CAP_EMLSR_SUPP plus EML padding delay (256 us, IEEE80211_EML_CAP_EML_PADDING_DELAY_256US since commit 5858f5e1588f ("wifi: Rename EMLSR delay constants and add EMLMR helpers and definitions")) and EMLSR transition delay (32 us) to match the EMLSR negotiation parameters Realtek's certified silicon supports.
mld_capa_and_ops is left at 0 (= MAX_SIMUL_LINKS field 0 = "1 max simultaneous link"), consistent with the EMLSR-only operating mode the driver implements per enum rtw89_mlo_mode {MLSR, EMLSR} (no STR mode in the driver despite WFA-cert silicon support).

Also add IEEE80211_EHT_MAC_CAP0_RESTRICTED_TWT to mac_cap_info[0]. The RTL8922A EHT MAC supports R-TWT for latency-sensitive scheduling; the cap bit was hard-zeroed alongside the other EHT mac/phy caps in rtw89_init_eht_cap().

Tested on RTL8922AU (USB variant, same MAC + RF as cert'd PCIe AE) against TP-Link Deco BE63 mesh: dual-link MLO assoc works (active_links = 0x4 confirms expected EMLSR mode, Link 2 / 6 GHz active), 60h+ stable association, 11/11 wifi-health-check probes pass, no kernel warnings or wpa_supplicant errors.

Note on EMLMR (EML Cap bit 7, IEEE80211_EML_CAP_EMLMR_SUPPORT): not advertised. The WFA cert does NOT list EMLMR for this chip. RTL8922A has rf_path_num=2 (single 2T2R RF block shared across 2.4, 5, 6 GHz), and the driver has no EMLMR enum, firmware H2C path, or PHY register block. EMLSR is the architectural ceiling for this silicon.

---
 drivers/net/wireless/realtek/rtw89/core.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

index 70feab97dccb..056639db1dfa 100644
@@ -217,7 +217,10 @@ static const struct wiphy_iftype_ext_capab rtw89_iftypes_ext_capa[] = {
 		.extended_capabilities_mask = rtw89_ext_capa_sta,
 		.extended_capabilities_len = sizeof(rtw89_ext_capa_sta),
 		/* relevant only if EHT is supported */
-		.eml_capabilities = 0,
+		.eml_capabilities =
+			IEEE80211_EML_CAP_EMLSR_SUPP |
+			(IEEE80211_EML_CAP_EML_PADDING_DELAY_256US << 1) |
+			(IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_32US << 4),
 		.mld_capa_and_ops = 0,
 	},
 };

@@ -5557,7 +5560,8 @@ static void rtw89_init_eht_cap(struct rtw89_dev *rtwdev,
 
 	eht_cap_elem->mac_cap_info[0] =
 		u8_encode_bits(chip->max_eht_mpdu_cap,
-			       IEEE80211_EHT_MAC_CAP0_MAX_MPDU_LEN_MASK);
+			       IEEE80211_EHT_MAC_CAP0_MAX_MPDU_LEN_MASK) |
+		IEEE80211_EHT_MAC_CAP0_RESTRICTED_TWT;
 	eht_cap_elem->mac_cap_info[1] = 0;
 
 	eht_cap_elem->phy_cap_info[0] =

2.54.0

Wi-Fi Alliance Certificate WFA129313 (RTL8922AE, 2024-05-23, firmware 6102.24.109.0) attests "Multi-RU" as a certified Wi-Fi 7 feature for this chip. The driver currently hard-zeroes the corresponding receive cap bit in rtw89_init_eht_cap(), which prevents the AP from scheduling Multi-RU OFDMA TBF (Trigger-Based Frame) payloads with sub-242-tone RU allocations to this STA.

Set IEEE80211_EHT_PHY_CAP5_RX_LESS_242_TONE_RU_SUPP in phy_cap_info[5] to match the certified silicon behaviour. The Tx-side bit (CAP5_TX_LESS_242_TONE_RU_SUPP) remains zero since this driver is STA-mode only and Tx of Multi-RU TBFs is an AP-mode capability.

Tested on RTL8922AU (USB variant, same MAC + RF as cert'd PCIe AE) against TP-Link Deco BE63 mesh; STA associates and remains stable for 24h+ with no regression in single-RU traffic patterns or in EMLSR multi-link assoc behavior introduced by the previous EML+R-TWT patch.

---
 drivers/net/wireless/realtek/rtw89/core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

index 056639db1dfa..986deb2c1384 100644
@@ -5598,7 +5598,8 @@ static void rtw89_init_eht_cap(struct rtw89_dev *rtwdev,
 
 	eht_cap_elem->phy_cap_info[5] =
 		u8_encode_bits(IEEE80211_EHT_PHY_CAP5_COMMON_NOMINAL_PKT_PAD_20US,
-			       IEEE80211_EHT_PHY_CAP5_COMMON_NOMINAL_PKT_PAD_MASK);
+			       IEEE80211_EHT_PHY_CAP5_COMMON_NOMINAL_PKT_PAD_MASK) |
+		IEEE80211_EHT_PHY_CAP5_RX_LESS_242_TONE_RU_SUPP;
 
 	eht_cap_elem->phy_cap_info[6] = 0;
 	eht_cap_elem->phy_cap_info[7] = 0;

2.54.0

Wi-Fi Alliance Certificate WFA129313 (RTL8922AE 802.11be and Bluetooth combo module, 2024-05-23, FW 6102.24.109.0) certifies both "Advertised TID-to-link mapping" and "Multi-link reconfiguration (AP removal/restart)" as Wi-Fi 7 features for this chip. The driver currently sets mld_capa_and_ops = 0, so the STA negotiates neither capability with the AP.

Use FIELD_PREP_CONST() (already used elsewhere in this driver, see usb.c:784-787) to set IEEE80211_MLD_CAP_OP_TID_TO_LINK_MAP_NEG_SUPP_SAME in the TID-to-link-map-neg-supp field, plus IEEE80211_MLD_CAP_OP_LINK_RECONF_SUPPORT. This matches the value used by iwlwifi for its Wi-Fi 7 STA mode (see drivers/net/wireless/intel/iwlwifi/ mld/mac80211.c IWL_MLD_CAPA_OPS macro and mvm/mac80211.c IWL_MVM_MLD_CAPA_OPS macro), which is the established in-tree precedent for this exact bit pattern on a Wi-Fi 7 STA.

The IEEE80211_MLD_CAP_OP_MAX_SIMUL_LINKS field is left at 0 (= 1 max simultaneous link, matching the EMLSR-only operating mode the driver implements per enum rtw89_mlo_mode {MLSR, EMLSR}).

These two capabilities are orthogonal to MLO operating mode (EMLSR remains the negotiated mode per the previous patch in this series); they let the AP perform online TID-to-link reassignments and remove or restart links without a full assoc cycle on the STA side.

Tested on RTL8922AU (USB variant, same MAC + RF as cert'd PCIe AE) against TP-Link Deco BE63 mesh; assoc remains stable, no regression in EMLSR multi-link assoc behavior, all 11 wifi-health-check probes pass.

---
 drivers/net/wireless/realtek/rtw89/core.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

index 986deb2c1384..aedb2a284cd4 100644
@@ -221,7 +221,10 @@ static const struct wiphy_iftype_ext_capab rtw89_iftypes_ext_capa[] = {
 			IEEE80211_EML_CAP_EMLSR_SUPP |
 			(IEEE80211_EML_CAP_EML_PADDING_DELAY_256US << 1) |
 			(IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_32US << 4),
-		.mld_capa_and_ops = 0,
+		.mld_capa_and_ops =
+			FIELD_PREP_CONST(IEEE80211_MLD_CAP_OP_TID_TO_LINK_MAP_NEG_SUPP,
+					 IEEE80211_MLD_CAP_OP_TID_TO_LINK_MAP_NEG_SUPP_SAME) |
+			IEEE80211_MLD_CAP_OP_LINK_RECONF_SUPPORT,
 	},
 };
 

2.54.0

Wi-Fi Alliance Certificate WFA129313 (RTL8922AE, 2024-05-23, firmware 6102.24.109.0) certifies "Operating mode indication" as a Wi-Fi 7 feature for this chip. The driver currently sets only MAX_MPDU_LEN + RESTRICTED_TWT in mac_cap_info[0], leaving EHT OM Control unset.

Set IEEE80211_EHT_MAC_CAP0_OM_CONTROL in mac_cap_info[0]. EHT OM Control extends the HE OMI control mechanism (already advertised at the HE layer) to EHT-specific operating-mode notifications. mt76 (mt7996, mt7925) and iwlwifi mvm + mld already set this single bit for their Wi-Fi 7 STAs; hwsim sets it in test code.

Tested on RTL8922AU against TP-Link Deco BE63; assoc + EMLSR multi- link state remain stable.

---
 drivers/net/wireless/realtek/rtw89/core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

index aedb2a284cd4..229c9f8ea65e 100644
@@ -5564,7 +5564,8 @@ static void rtw89_init_eht_cap(struct rtw89_dev *rtwdev,
 	eht_cap_elem->mac_cap_info[0] =
 		u8_encode_bits(chip->max_eht_mpdu_cap,
 			       IEEE80211_EHT_MAC_CAP0_MAX_MPDU_LEN_MASK) |
-		IEEE80211_EHT_MAC_CAP0_RESTRICTED_TWT;
+		IEEE80211_EHT_MAC_CAP0_RESTRICTED_TWT |
+		IEEE80211_EHT_MAC_CAP0_OM_CONTROL;
 	eht_cap_elem->mac_cap_info[1] = 0;
 
 	eht_cap_elem->phy_cap_info[0] =

2.54.0

Wi-Fi Component Operating System: Windows

That means hardware is capable, but Linux driver might need more implementation, not just declaration. I will ask internal to check them.

But I think it is not necessary to add this link as reference.

[...]

I'd like to know if these patches have explicit improvement to you? Or you only test these without regression?

As I know, at least TTLM needs to apply configuration to hardware and firmware. Without necessary changes, it should not work properly.

Ping-Ke

Agreed on both points, thanks for the correction. I went back over each capability with that lens, and it changed the series more than I expected:

- TTLM (was 3/4): you are right. H2C_FUNC_MLO_TTLM is defined but not wired anywhere in the driver, so advertising it would be declaration without implementation. Dropped.

- Restricted TWT (was part of 1/4): no in-tree driver advertises IEEE80211_EHT_MAC_CAP0_RESTRICTED_TWT for a STA today, and I cannot verify what the firmware needs. Dropped.

- Rx 1024/4096-QAM in less-than-242-tone RU (was 2/4): I had mischaracterized this bit as generic multi-RU receive support; it is specifically about high-order QAM on small RUs, which I cannot verify at the PHY level. Dropped.

- EHT OM Control (was 4/4): the drivers that set this for a STA (iwlwifi, mt7925) also advertise HE OMI control on the STA iftype, which rtw89 sets only for AP. Advertising the EHT extension without the HE base looked inconsistent, so I dropped it rather than widen the change to the shared HE path.

If your internal check concludes any of these are supportable as-is, I am happy to bring them back as follow-ups with the right justification.

Only the EML capabilities patch has an explicit improvement: in A/B testing on my RTL8922AU against a TP-Link Deco BE63, ML association without it came up with a single link, and with it both the 5 GHz and 6 GHz links are set up (debugfs link-1/link-2, active_links behaving as expected for EMLSR), stable across 60+ hour soaks. The other three were no-regression only, which is part of why v2 drops them.

v2 is therefore that single patch, and follows.

Louis

It is also like other features.

With this declaration, it will handshake two links in protocol point of view, so you can see two links in debugfs, but actually it operates on one of the links since driver isn't implemented to configure hardware and firmware.

So, I'd defer this patch. Internally, we are still cooking to enable this feature.

Ping-Ke

Understood, and that makes sense. Advertising the capability without the hardware and firmware configuration behind it would be misleading to the peer, and my A/B only established that the links are set up at the protocol level, which is exactly the part you are granting. I did not measure per-link radio activity, so I have nothing that speaks to whether EMLSR actually runs.

Dropping the patch, and I will not resend it.

When the EMLSR enablement is ready, I am happy to test it. I have an RTL8922AU (USB) associated to a Wi-Fi 7 AP MLD with an A/B capture rig already set up, so I can report on real multi-link behaviour rather than just the association state. Please Cc me if that would be useful.

Thanks for taking the time on the series.

Louis

(Resent as plain text; the original copy was rejected by the list for containing an HTML part. Apologies for the duplicate, Ping-Ke.)