The driver implements the EMLSR operating mode for 8922a and selects it when an interface has more than one active link (enum rtw89_mlo_mode, rtw89_ops_vif_cfg_changed()), but leaves eml_capabilities = 0 in the STA iftype-ext-cap. mac80211 therefore advertises no EML capabilities in the Multi-Link element, so an EMLSR-capable AP cannot negotiate EMLSR with this STA. Populate eml_capabilities with IEEE80211_EML_CAP_EMLSR_SUPP, an EML padding delay of 256 us and an EMLSR transition delay of 32 us, following the same layout iwlwifi uses (iwlwifi advertises 32 us and 64 us). These values have run stably on my RTL8922AU since late April; if Realtek has recommended values for this silicon I am happy to adjust them. In A/B testing against a TP-Link Deco BE63 (EMLSR-capable Wi-Fi 7 AP), ML association without this change came up with a single link; with it, both the 5 GHz and 6 GHz links are set up (debugfs shows link-1 and link-2 with active_links behaving as expected for EMLSR), stable across 60+ hour soaks with no kernel or wpa_supplicant errors. EMLMR is deliberately not advertised: the chip has a single shared 2T2R RF block (rf_path_num = 2) and the driver has no EMLMR mode, so EMLSR is the architectural ceiling for this silicon. Realtek's Wi-Fi Alliance certification of RTL8922AE (WFA129313) likewise lists EMLSR but not EMLMR; the certification was obtained with the Windows driver, so it is cited only as evidence of silicon and firmware capability. Signed-off-by: Louis Kotze --- Changes in v2 (was patch 1/4 of "advertise WFA-certified EHT capabilities for 8922a"): - Narrowed the series to this single patch; see the reply on the v1 thread for why the other three capabilities are deferred. - Dropped Restricted TWT from this patch: no in-tree driver advertises it for a STA yet and I cannot verify the firmware side. - Dropped the WFA certificate Link: trailer; the certification was obtained with the Windows driver, so it is cited in the body only as silicon-side evidence. - Stated the advertised delay values and their testing basis explicitly, and switched to the __bf_shf() layout iwlwifi uses. - Rebased onto wireless-next; also applies cleanly on rtw-next (2b7858891b10). drivers/net/wireless/realtek/rtw89/core.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wireless/realtek/rtw89/core.c index 0f0e46cb4260..69eaae3586cb 100644 --- a/drivers/net/wireless/realtek/rtw89/core.c +++ b/drivers/net/wireless/realtek/rtw89/core.c @@ -217,7 +217,12 @@ 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 << + __bf_shf(IEEE80211_EML_CAP_EML_PADDING_DELAY) | + IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_32US << + __bf_shf(IEEE80211_EML_CAP_EML_TRANSITION_DELAY), .mld_capa_and_ops = 0, }, }; base-commit: ac798f757d6475dc6fee2ec899980d6740714596 -- 2.55.0