[RFC PATCH 0/4] wifi: rtw89: add NL80211_IFTYPE_P2P_DEVICE support
andres parra <[email protected]>
| Newsgroups | org.kernel.vger.linux-wireless |
|---|---|
| Message-ID | <[email protected]> |
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(-)
--
2.55.0