[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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.