[PATCH v2] wifi: rtw89: advertise EML capabilities for 8922a

[Louis Kotze <loukot@gmail.com>]

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 <loukot@gmail.com>
---
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