Skip to content

RFC wifi: rtw89: add NL80211_IFTYPE_P2P_DEVICE support

andres parra linux-wireless 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest4 patches 3 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/4wifi: rtw89: declare P2P_DEVICE in interface modes/combinationscore.c+10 -10 replies
2/4wifi: rtw89: map P2P_DEVICE to RTW89_WIFI_ROLE_P2P_DEVICEcore.c+1 -00 replies
3/4wifi: rtw89: handle P2P_DEVICE in net_type/self_role switchcore.c+1 -00 replies
4/4wifi: rtw89: raise RTW89_MAX_INTERFACE_NUM to 3 for P2P-Device concurrencycore.h+1 -10 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [RFC PATCH 0/4] wifi: rtw89: add NL80211_IFTYPE_P2P_DEVICE support

Hi,

I'm not a professional kernel developer -- this is my first substantive contribution to this subsystem, so please bear with me if anything here doesn't follow convention, and I'd appreciate direct correction on anything I've gotten wrong.

rtw89 does not currently declare NL80211_IFTYPE_P2P_DEVICE anywhere in interface_modes, which means wpa_supplicant/NetworkManager can never create a real P2P-Device wdev on this hardware, and Wi-Fi Direct casting (Miracast/WFD) to a smart TV never works: GO negotiation never even starts. Confirmed absent across every rtw89 chip variant, not just RTL8922AE. mt792x (mt7921/7922/7925) implements this correctly on comparable modern, MCU-firmware-based hardware, and was used as the reference model for this series.

This series adds it: 4 small, independent commits, RTL8922AE tested. No new driver ops are needed -- mac80211 core itself already implements start_p2p_device/stop_p2p_device generically (net/mac80211/cfg.c) and dispatches straight to add_interface with vif->type == NL80211_IFTYPE_P2P_DEVICE, so the whole change is:
declaring the interface mode + a matching iface_limit entry (patch 1), extending two existing role-mapping switch statements in rtw89_vif_type_mapping() that previously hit WARN_ON(1) for this type (patches 2-3), and raising RTW89_MAX_INTERFACE_NUM from 2 to 3 so a P2P-Device wdev can coexist with an active STA connection and the resulting P2P-Client group link (patch 4) -- traced that this doesn't strain the separate, firmware-tied NUM_OF_RTW89_MCC_ROLES limit (still 2, unchanged), since a P2P-Device link's remain_on_channel never acquires a real chanctx assignment and so never occupies an MCC-role slot.

Tested live on real hardware (RTL8922AE, current firmware 0.35.80.3), out-of-tree build against this series synced to current
mainline: a real P2P-Device wdev appears (confirmed via iw dev), wpa_supplicant completes real GO negotiation against an actual Wi-Fi Display TV (P2P-GO-NEG-SUCCESS), and a full Miracast cast completes end to end and stays up for extended real use, with the laptop remaining connected to its normal AP throughout and no regression to normal STA association/roaming observed. checkpatch --strict clean on all 4 patches.

Two things found during testing that I could not root-cause myself and would appreciate guidance on -- happy to help gather more diagnostics if useful:

1. If the AP the STA link is associated to does an ordinary channel switch (CTRL-EVENT-CHANNEL-SWITCH) onto a different channel than the one an active P2P-Client group is using, the P2P link is dropped outright (beacon loss, then a locally-generated disconnect) and never re-established automatically. I don't know whether this is a pre-existing limitation in the existing MCC entity-management code (rtw89_entity_mgnt / chan.c) that would reproduce identically with a stock, unmodified P2P_CLIENT/GO connection unrelated to this series, or something specific to a P2P-Device wdev being present. Have not yet had the chance to test against a stock driver to isolate which.

2. If the STA link and the P2P-Client link end up on genuinely different *bands* (STA on 5GHz, P2P on 2.4GHz -- WFD is 2.4GHz-only) rather than just different channels on the same band, the connection stays up but has a real, repeatable performance cost -- confirmed clean at the RF link level (zero tx retries/failures on the P2P link, good signal, decent PHY rate throughout) via station dump, so it doesn't look like a radio-quality problem. Grepped this driver for any equivalent to Intel iwlwifi's CDB (Concurrent Dual-Band, IWL_UCODE_TLV_CAPA_CDB_SUPPORT, a distinct LMAC per band) or MediaTek mt76's DBDC (Dual-Band Dual-Concurrent, MCU_EXT_CMD_DBDC_CTRL) -- found nothing under either name. Is that because RTL8922AE genuinely lacks equivalent hardware/firmware capability (in which case this is a real ceiling, not something software can fix), or does it exist under different terminology I haven't found?

Grateful for any review, and for pointing out anything I've missed -- this is my first time working this deep in a wireless driver and I know there's a lot I don't know.

Thanks,
Andres

andres parra (4):
wifi: rtw89: declare P2P_DEVICE in interface modes/combinations
wifi: rtw89: map P2P_DEVICE to RTW89_WIFI_ROLE_P2P_DEVICE
wifi: rtw89: handle P2P_DEVICE in net_type/self_role switch
wifi: rtw89: raise RTW89_MAX_INTERFACE_NUM to 3 for P2P-Device
concurrency

 core.c | 13 ++++++++++++-
 core.h |  2 +-
 2 files changed, 13 insertions(+), 2 deletions(-)
Signature · 1 line
2.55.0