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

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

[andres parra]

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

[RFC PATCH 1/4] wifi: rtw89: declare P2P_DEVICE in interface modes/combinations

[andres parra]

Add BIT(NL80211_IFTYPE_P2P_DEVICE) to hw->wiphy->interface_modes, and a
dedicated { .max = 1, .types = BIT(NL80211_IFTYPE_P2P_DEVICE) } limit
entry to both rtw89_iface_limits[] and rtw89_iface_limits_mcc[],
mirroring how mt792x (mt7921/7922/7925) scopes the same interface type
in its own iface_limit tables rather than merging it into the existing
AP/P2P_CLIENT/P2P_GO bucket.

RTW89_MAX_INTERFACE_NUM (2) is left untouched: it also sizes
rtw89_entity_mgnt's active_roles[]/chanctx_tbl[][] arrays, a real
firmware-resource-tracking constraint, not just a wiphy-advertised
limit. This keeps the new P2P-Device bucket within the existing cap
(e.g. STATION + P2P-Device concurrently), and explicitly defers full
3-way concurrency (STATION + P2P-Client/GO + P2P-Device at once) to a
later change, rather than growing those tracking arrays speculatively.

This commit is purely declarative: no code path creates a P2P-Device
vif yet, so no runtime behavior change is expected for any existing
interface type. Part 1 of 2 for NL80211_IFTYPE_P2P_DEVICE support;
see rtw89-p2p-device-project's PLAN.md/BUILD_LOG.md for the full
research and design behind this change.

Signed-off-by: andres parra <andres.parrab@gmail.com>
---
 core.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/core.c b/core.c
index 397ebbf..5cf29bf 100644
--- a/core.c
+++ b/core.c
@@ -176,6 +176,10 @@ static const struct ieee80211_iface_limit rtw89_iface_limits[] = {
 			 BIT(NL80211_IFTYPE_P2P_GO) |
 			 BIT(NL80211_IFTYPE_AP),
 	},
+	{
+		.max = 1,
+		.types = BIT(NL80211_IFTYPE_P2P_DEVICE),
+	},
 };
 
 static const struct ieee80211_iface_limit rtw89_iface_limits_mcc[] = {
@@ -188,6 +192,10 @@ static const struct ieee80211_iface_limit rtw89_iface_limits_mcc[] = {
 		.types = BIT(NL80211_IFTYPE_P2P_CLIENT) |
 			 BIT(NL80211_IFTYPE_P2P_GO),
 	},
+	{
+		.max = 1,
+		.types = BIT(NL80211_IFTYPE_P2P_DEVICE),
+	},
 };
 
 static const struct ieee80211_iface_combination rtw89_iface_combs[] = {
@@ -7517,7 +7525,8 @@ static int rtw89_core_register_hw(struct rtw89_dev *rtwdev)
 	hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
 				     BIT(NL80211_IFTYPE_AP) |
 				     BIT(NL80211_IFTYPE_P2P_CLIENT) |
-				     BIT(NL80211_IFTYPE_P2P_GO);
+				     BIT(NL80211_IFTYPE_P2P_GO) |
+				     BIT(NL80211_IFTYPE_P2P_DEVICE);
 
 	if (hal->ant_diversity) {
 		hw->wiphy->available_antennas_tx = 0x3;
-- 
2.55.0

[RFC PATCH 2/4] wifi: rtw89: map P2P_DEVICE to RTW89_WIFI_ROLE_P2P_DEVICE

[andres parra]

Extend rtw89_vif_type_mapping()'s switch with
RTW89_TYPE_MAPPING(P2P_DEVICE), same generic macro already used for
ADHOC/MONITOR/MESH_POINT. Without this, a P2P-Device vif reaching this
function (now possible after the previous commit advertised the mode)
would fall through to the default: WARN_ON(1) case.

RTW89_WIFI_ROLE_P2P_DEVICE already existed in enum rtw89_wifi_role
before this change, and every existing consumer of wifi_role
(chan.c, ps.c, phy.c, coex.c) already handles it correctly by falling
through their "not STATION"/"not P2P_CLIENT" branches, since a
P2P-Device role has no BSS/association state those checks assume for
other roles. The BT-coexistence firmware command path
(RTW89_SET_FWCMD_CXROLE_ROLE_P2P_DEV in fw.c, three call sites) already
consumes this role generically via a role-bitmap built from
rtw89_vif_type_mapping()'s output, so this one-line mapping is
sufficient to make P2P-Device role signaling to firmware work with no
further changes needed there.

Part 2 of 2 for NL80211_IFTYPE_P2P_DEVICE support. Together with the
previous commit, this is the full v1 diff per this project's Phase 2
design (see rtw89-p2p-device-project's PLAN.md/BUILD_LOG.md): a real,
startable/stoppable P2P-Device wdev with working BT-coex signaling and
remain_on_channel (already present on this chip/firmware, unaffected
by this change). No start_p2p_device/stop_p2p_device driver ops are
needed -- mac80211 core (net/mac80211/cfg.c) implements those
generically and calls the ordinary add_interface/remove_interface ops,
which require no vif->type-specific handling on this driver (confirmed
by reading rtw89_ops_add_interface() in full).

Signed-off-by: andres parra <andres.parrab@gmail.com>
---
 core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/core.c b/core.c
index 5cf29bf..c8f12ef 100644
--- a/core.c
+++ b/core.c
@@ -5702,6 +5702,7 @@ void rtw89_vif_type_mapping(struct rtw89_vif_link *rtwvif_link, bool assoc)
 	RTW89_TYPE_MAPPING(ADHOC);
 	RTW89_TYPE_MAPPING(MONITOR);
 	RTW89_TYPE_MAPPING(MESH_POINT);
+	RTW89_TYPE_MAPPING(P2P_DEVICE);
 	default:
 		WARN_ON(1);
 		break;
-- 
2.55.0

[RFC PATCH 3/4] wifi: rtw89: handle P2P_DEVICE in net_type/self_role switch

[andres parra]

rtw89_vif_type_mapping() has a second switch (vif->type) beyond the
wifi_role mapping already fixed -- this one sets net_type/self_role
and also ends in a default: WARN_ON(1). Live-tested on real hardware
(RTL8922AE): the moment wpa_supplicant/NetworkManager requested a
P2P-Device wdev (NL80211_CMD_START_P2P_DEVICE), this WARN_ON fired
immediately, confirmed via the exact call chain this project's
BUILD_LOG.md had already traced by hand: nl80211_start_p2p_device ->
ieee80211_start_p2p_device -> ieee80211_do_open -> drv_add_interface ->
rtw89_ops_add_interface -> __rtw89_ops_add_iface_link ->
rtw89_vif_type_mapping.

This second switch was present in the original research grep
(core.c:5702, two switch(vif->type) sites found) but was not actually
read/analyzed at the time -- a real gap in that research pass, caught
by this live test rather than by review.

Add NL80211_IFTYPE_P2P_DEVICE alongside the existing MONITOR case,
which also just breaks without setting net_type/self_role: a
P2P-Device interface has no BSS/association state, so leaving these at
their zero-initialized defaults (RTW89_NET_TYPE_NO_LINK,
RTW89_SELF_ROLE_CLIENT) is correct, same reasoning already applied to
MONITOR.

Verified live: after this fix, wpa_supplicant successfully created a
real P2P-Device wdev (confirmed via `iw dev`: phy#1 now lists a
non-netdev interface, type P2P-device, alongside wlan0), with zero
WARN/BUG in dmesg for the whole boot, and normal STA association/
roaming continuing to work correctly (multiple successful associate/
reassociate cycles observed with this driver loaded).

Signed-off-by: andres parra <andres.parrab@gmail.com>
---
 core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/core.c b/core.c
index c8f12ef..b4f8d27 100644
--- a/core.c
+++ b/core.c
@@ -5734,6 +5734,7 @@ void rtw89_vif_type_mapping(struct rtw89_vif_link *rtwvif_link, bool assoc)
 		rtwvif_link->addr_cam.sec_ent_mode = RTW89_ADDR_CAM_SEC_NORMAL;
 		break;
 	case NL80211_IFTYPE_MONITOR:
+	case NL80211_IFTYPE_P2P_DEVICE:
 		break;
 	default:
 		WARN_ON(1);
-- 
2.55.0

[RFC PATCH 4/4] wifi: rtw89: raise RTW89_MAX_INTERFACE_NUM to 3 for P2P-Device concurrency

[andres parra]

Live-tested last night: a real GO negotiation against an actual TV
succeeded (P2P-GO-NEG-SUCCESS), but forming the actual data connection
failed with P2P-GROUP-FORMATION-FAILURE while the laptop stayed
connected to its normal STA WiFi -- completing the cast needs three
concurrent interfaces (STA + P2P-Device + the new P2P-Client group
link), and RTW89_MAX_INTERFACE_NUM was deliberately left at 2 in the
v1 design.

Traced whether raising this strains the driver's separate,
firmware-capability-tied MCC (Multi-Channel-Concurrent) role limit,
NUM_OF_RTW89_MCC_ROLES (= 2, unrelated to this constant, chan.h:51):
it does not. rtw89_entity_mgnt's active_roles[]/chanctx_tbl[][] arrays
(sized by RTW89_MAX_INTERFACE_NUM) are only populated for links with
chanctx_assigned == true, which is set in exactly one place --
rtw89_chanctx_ops_assign_vif(), the assign_vif_chanctx driver op --
and a P2P-Device vif's remain_on_channel is dispatched straight to the
driver's native ROC op, bypassing assign_vif_chanctx entirely (already
established: this only applies to emulate_chanctx-less drivers, which
this chip is not). So a P2P-Device link's chanctx_assigned stays false
for its whole lifetime and never occupies an MCC-role slot -- in the
real STA+P2P-Device+P2P-Client scenario, only STA and the P2P-Client
link ever get a real chanctx assignment, exactly matching
NUM_OF_RTW89_MCC_ROLES = 2, unchanged and unstrained.

The actual P2P-GROUP-FORMATION-FAILURE originates purely at the
mac80211/cfg80211 layer (ieee80211_check_combinations(), a plain
interface-count check against wiphy->iface_combinations[].max_interfaces,
itself set from this constant) -- this one-line change is the complete
fix for that. rtw89_iface_combs[]'s max_interfaces fields and
rtw89_entity_mgnt's array sizes already reference the macro
symbolically, so both grow automatically with no separate edit.
static_assert(RTW89_MAX_INTERFACE_NUM >= NUM_OF_RTW89_MCC_ROLES) still
holds (3 >= 2). Full research trail in this project's BUILD_LOG.md.

Signed-off-by: andres parra <andres.parrab@gmail.com>
---
 core.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/core.h b/core.h
index 2b21d96..83675f0 100644
--- a/core.h
+++ b/core.h
@@ -6340,7 +6340,7 @@ enum rtw89_entity_mode {
 	RTW89_ENTITY_MODE_UNHANDLED = -ESRCH,
 };
 
-#define RTW89_MAX_INTERFACE_NUM 2
+#define RTW89_MAX_INTERFACE_NUM 3
 
 /* only valid when running with chanctx_ops */
 struct rtw89_entity_mgnt {
-- 
2.55.0

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

[Ping-Ke Shih]

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. 

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

[andres parra]

Hi Ping-Ke,

Thanks for the quick, detailed reply -- really appreciate it. I applied
patches 11-14 from your series (git am -p6 straight onto a clean sync
of core.c/core.h/chan.c/chan.h/debug.c/fw.c/ps.c/regd.c/util.h against
current mainline, since I don't have a full rtw-next checkout set up
yet) and tested on the same RTL8922AE hardware.

Results:

- Built clean, loaded clean, zero WARN/BUG in dmesg through the whole
  test.
- Real P2P-Device wdev appears (confirmed via `iw dev`), same as with
  my own patch.
- Real P2P discovery, GO negotiation (P2P-GO-NEG-SUCCESS), and full
  group formation against my actual Wi-Fi Display TV, tested twice:
  once with raw wpa_cli, once through a real WFD casting application
  (different encoder/bitrate settings each time). Both completed
  successfully, real DHCP lease on the resulting P2P-Client interface,
  real video actually displaying on the TV.
- No regression to normal STA association/roaming with your patches
  loaded.

On the two things I asked about:

1. Cross-band cost: confirmed reproducible with your patches too, and
   it matches your explanation exactly -- forced the STA link onto
   5GHz while the P2P-Client link stayed on 2.4GHz (same channel it
   started on), and casting became noticeably choppier, then smooth
   again once STA moved back to 2.4GHz. Consistent with TDMA timeslot
   sharing rather than a bug in either patch set.

2. Same-band channel-switch disconnect: reproduced it with your
   patches too, while writing this email. My AP did a real, ordinary
   channel switch on the STA link (CTRL-EVENT-STARTED-CHANNEL-SWITCH
   -> CTRL-EVENT-CHANNEL-SWITCH, 2462 MHz -> 2412 MHz, i.e. channel 11
   to channel 1, both 2.4 GHz), while the P2P-Client link was still
   active on channel 11. Result, same signature as with my own patch:

     p2p-wlanX-Y: CTRL-EVENT-BEACON-LOSS
     p2p-wlanX-Y: CTRL-EVENT-DISCONNECTED bssid=<GO> reason=4 locally_generated=1
     P2P-GROUP-REMOVED p2p-wlanX-Y client reason=IDLE

   No automatic recovery -- the group is gone, casting stops, no crash
   or kernel WARN/BUG (dmesg clean, system otherwise fully stable,
   STA link itself reconnects fine on the new channel). So this one is
   confirmed **not** fixed by patches 11-14 -- same behavior as
   before your series was applied. Happy to test whatever you'd
   suggest, or dig into rtw89_entity_mgnt/chan.c myself if that's
   useful, now that patch 11 gave me a clearer read on that code.

Test flow, as asked, for reference:
  wpa_cli -i p2p-dev-wlan0 p2p_find
  wpa_cli -i p2p-dev-wlan0 p2p_connect <TV MAC> pbc go_intent=0
  (watch for P2P-GO-NEG-SUCCESS / P2P-GROUP-STARTED in
  journalctl -u wpa_supplicant)
  -- then wait for or induce a real AP-side channel switch on the STA
  link (I couldn't force mine reliably; this one happened on its own
  from the AP), watch for CTRL-EVENT-CHANNEL-SWITCH on the STA link
  followed by whatever happens to the P2P-Client link.

Given your team already has a complete, working implementation with
real fixes I wouldn't have found on my own (the 6 GHz regd recalc
issue, the entity-pause/tracking interaction), I'll hold off on
pushing my own patches further -- happy to keep helping test yours on
real hardware instead, since that seems like the more useful thing I
can offer here. Thanks again for taking the time to look at this and
point me in the right direction.

Andres

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

[Ping-Ke Shih]

andres parra <andres.parrab@gmail.com> wrote:
> On the two things I asked about:
> 
> 1. Cross-band cost: confirmed reproducible with your patches too, and
>    it matches your explanation exactly -- forced the STA link onto
>    5GHz while the P2P-Client link stayed on 2.4GHz (same channel it
>    started on), and casting became noticeably choppier, then smooth
>    again once STA moved back to 2.4GHz. Consistent with TDMA timeslot
>    sharing rather than a bug in either patch set.

It depends on the bandwidth the casting needs. 

The TDMA timeslot is assigned according to TBTT of AP and GO, but the
DUT (RTL8922AE) plays STA and GC, which he has no way to arrange a
good TBTT to yield 50/50 timeslot for 2/5GHz bands.

Which means if DUT is STA and GO, it will try it best to share the
timeslot for two roles.

> 
> 2. Same-band channel-switch disconnect: reproduced it with your
>    patches too, while writing this email. My AP did a real, ordinary
>    channel switch on the STA link (CTRL-EVENT-STARTED-CHANNEL-SWITCH
>    -> CTRL-EVENT-CHANNEL-SWITCH, 2462 MHz -> 2412 MHz, i.e. channel 11
>    to channel 1, both 2.4 GHz),

Do you know why your AP want to switch from channel 11 to channel 1?
Or you manually control it to do so?

>    while the P2P-Client link was still
>    active on channel 11. Result, same signature as with my own patch:
> 
>      p2p-wlanX-Y: CTRL-EVENT-BEACON-LOSS
>      p2p-wlanX-Y: CTRL-EVENT-DISCONNECTED bssid=<GO> reason=4 locally_generated=1
>      P2P-GROUP-REMOVED p2p-wlanX-Y client reason=IDLE

In our side, the setup below can work with RTL8922AE firmware v0.35.115.2
(not release yet; and it will be public soon)

PC#1  (AP)
   wls1 -> softap (ch 11)
   hostapd_cli wls1 ... [A]
PC#2  (GO)
   wpa_cli p2p-dev-wls1 p2p_group_add -> [p2p-wls1-0] p2p-GO (ch 11)
   wpa_cli p2p-wls1-0 ... [B]
PC#3  (STA + GC)
   wpa_cli wls1 -> connect to PC#1 sotap
   wpa_cli p2p-dev-wls1 ... [C]
   Then,
   make p2p connection via [B] and [C] -> PC#3 becomes SCC (ch 11 + ch 11)
 
   Finally,
   set chan_switch via [A] -> PC#1 becomes ch 1 -> PC#3 becomes MCC (ch 1 + ch 11)
   (chan_switch <cs_count> <freq>)

Ping-Ke