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

[Ping-Ke Shih <pkshih@realtek.com>]

andres parra <andres.parrab@gmail.com> wrote:
> 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.

You should apply your patch to kernel tree, and generate patches.
Otherwise, the path is wrong:
   diff --git a/core.c b/core.c

For Realtek WiFi drivers, the tree should be rtw-next [1].

It seems like you repeatedly describe similar messages in every
patch. Not sure if this is because the 4 patches are small. 

[1] https://github.com/pkshih/rtw.git rtw-next

> 
> 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.

We have developed this recently [2]. Please take patches 11/14 ~14/14
and test if it works in your side.

[2] https://lore.kernel.org/linux-wireless/20260826064101.58892-12-pkshih@realtek.com/T/#u

> 
> 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.

Could you try the same test on the patches I mentioned above?
And, share the test flow step by step.

> 
> 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?

rtw89 doesn't support dual bands concurrency simultaneously, it uses
power saving mechanism to do TDMA timeslot sharing.