[PATCH rtw-next] wifi: rtw88: 8723d: add iface combination

[PATCH rtw-next] wifi: rtw88: 8723d: add iface combination

[Carl Quist]

Allow 8723d to operate a station and an AP interface concurrently, using
the combination already enabled for 8822c: one station plus one AP on the
same channel.

Without it, the AP interface cannot be brought up while the station is
active (hostapd: "Could not set interface ap0 flags (UP): Device or
resource busy"), so an RTL8723DE laptop cannot share its Wi-Fi
connection.

Tested on RTL8723DE [10ec:d723], firmware 48.0.0, kernel 7.2.5, with
hostapd 2.12 on a second (AP) interface with its own MAC address:

- the AP ran beside the associated station on 2.4 GHz channel 1 (HT20)
  for about four hours and served a smartphone client;
- the AP was started and stopped repeatedly without affecting the
  station;
- with the AP running, the station was disconnected and reconnected
  four times; it re-associated within one second each time and the AP
  stayed up.

Assisted-by: LLM
Signed-off-by: Carl Quist <equalizerjr@gmail.com>
---

Notes:
    An AI coding assistant (Claude Opus 5.5) helped investigate this, write the
    change and run the tests above; I reviewed the change and tested it on my
    own RTL8723DE laptop.

 drivers/net/wireless/realtek/rtw88/main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index 0f23498..c64a3ba 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -2299,7 +2299,8 @@ int rtw_register_hw(struct rtw_dev *rtwdev, struct ieee80211_hw *hw)
 	hw->wiphy->max_scan_ssids = RTW_SCAN_MAX_SSIDS;
 	hw->wiphy->max_scan_ie_len = rtw_get_max_scan_ie_len(rtwdev);
 
-	if (rtwdev->chip->id == RTW_CHIP_TYPE_8822C) {
+	if (rtwdev->chip->id == RTW_CHIP_TYPE_8822C ||
+	    rtwdev->chip->id == RTW_CHIP_TYPE_8723D) {
 		hw->wiphy->iface_combinations = rtw_iface_combs;
 		hw->wiphy->n_iface_combinations = ARRAY_SIZE(rtw_iface_combs);
 	}
-- 
2.55.0

Re: [PATCH rtw-next] wifi: rtw88: 8723d: add iface combination

[Luka Gejak]

Hi Carl,

On Fri Oct 16, 2026 at 11:41 PM CEST, Carl Quist wrote:
> Allow 8723d to operate a station and an AP interface concurrently, using
> the combination already enabled for 8822c: one station plus one AP on the
> same channel.
>
> Without it, the AP interface cannot be brought up while the station is
> active (hostapd: "Could not set interface ap0 flags (UP): Device or
> resource busy"), so an RTL8723DE laptop cannot share its Wi-Fi
> connection.
>
> Tested on RTL8723DE [10ec:d723], firmware 48.0.0, kernel 7.2.5, with
> hostapd 2.12 on a second (AP) interface with its own MAC address:
>
> - the AP ran beside the associated station on 2.4 GHz channel 1 (HT20)
>   for about four hours and served a smartphone client;
> - the AP was started and stopped repeatedly without affecting the
>   station;
> - with the AP running, the station was disconnected and reconnected
>   four times; it re-associated within one second each time and the AP
>   stayed up.
>
> Assisted-by: LLM
> Signed-off-by: Carl Quist <equalizerjr@gmail.com>
> ---
>
> Notes:
>     An AI coding assistant (Claude Opus 5.5) helped investigate this, write the
>     change and run the tests above; I reviewed the change and tested it on my
>     own RTL8723DE laptop.
>
>  drivers/net/wireless/realtek/rtw88/main.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> index 0f23498..c64a3ba 100644
> --- a/drivers/net/wireless/realtek/rtw88/main.c
> +++ b/drivers/net/wireless/realtek/rtw88/main.c
> @@ -2299,7 +2299,8 @@ int rtw_register_hw(struct rtw_dev *rtwdev, struct ieee80211_hw *hw)
>  	hw->wiphy->max_scan_ssids = RTW_SCAN_MAX_SSIDS;
>  	hw->wiphy->max_scan_ie_len = rtw_get_max_scan_ie_len(rtwdev);
>  
> -	if (rtwdev->chip->id == RTW_CHIP_TYPE_8822C) {
> +	if (rtwdev->chip->id == RTW_CHIP_TYPE_8822C ||
> +	    rtwdev->chip->id == RTW_CHIP_TYPE_8723D) {
>  		hw->wiphy->iface_combinations = rtw_iface_combs;
>  		hw->wiphy->n_iface_combinations = ARRAY_SIZE(rtw_iface_combs);
>  	}

Where does the AP beacon fit in the reserved pages?

This chip has 8 pages of 128 bytes, while rtl8822c has 16, so the 8822c
never had to squeeze a beacon in next to the station pages.

A station vif always adds five reserved packets in
rtw_add_rsvd_page_sta() and each one is counted after
rtw_fill_rsvd_page_desc() adds the 40 byte tx descriptor. Four of them
take one page, rtw_lps_pg_dpk_hdr is 169 bytes and takes two, so 6 of
the 8 pages are gone before the beacon is even considered. The beacon is
first in the list and its descriptor counts too:

		total_page += rtw_len_to_page(iter->len + tx_desc_sz,
		                              page_size);

That leaves 2 pages, so the beacon has to stay <= 216 bytes. Past that
rtw_build_rsvd_page() fails with "rsvd page over size" and
rtw_fw_download_rsvd_page() returns before rtw_download_beacon() runs.
rtw_ops_bss_info_changed() ignores the error, so hostapd thinks the AP is
up but no beacon ever reaches the firmware.

I ran this on an RTL8723DU with your patch applied. A stock hostapd WPA2
beacon came to 188 bytes and 28 bytes of extra IE still fit. At 29 bytes
the driver logged "rsvd page over size: 9" and "failed to build rsvd page
pkt" while hostapd still reported the AP as enabled. Scans still list the
SSID because probe responses go out over the normal path, so the failure
is easy to miss.

A longer SSID, WPS or a vendor IE all add bytes to the beacon, so this is
easy to reach in everyday usage.

Can the station pages be trimmed while an AP is present, or maybe this
combination should only be used on the chips with the bigger page budget?

Best regards,
Luka Gejak

Re: [PATCH rtw-next] wifi: rtw88: 8723d: add iface combination

[Carl Quist]

Hi Luka,

Thanks for the review, and for testing it on an RTL8723DU.

On Sat Oct 17, 2026 at 10:41 AM, Luka Gejak wrote:
> Where does the AP beacon fit in the reserved pages?
>
> This chip has 8 pages of 128 bytes, while rtl8822c has 16, so the 8822c
> never had to squeeze a beacon in next to the station pages.

You are right, I missed this. I went through rtw_build_rsvd_page() and
get the same numbers: the five station packets take 6 of the 8 pages,
which leaves 2 pages, so the beacon must stay at or below 216 bytes.

> Can the station pages be trimmed while an AP is present, or maybe this
> combination should only be used on the chips with the bigger page budget?

I think they can be trimmed for every station, not only while an AP is
present. Two of the five packets, RSVD_LPS_PG_DPK and RSVD_LPS_PG_INFO,
take 3 pages, but their locations are only read by rtw_fw_set_pg_info(),
which only runs in LPS_DEEP_MODE_PG. rtw_update_lps_deep_mode() never
picks that mode unless the chip sets BIT(LPS_DEEP_MODE_PG) in
lps_deep_mode_supported, and only 8822c does; 8723d has 0.

So for v2 I plan to add a patch before this one that only reserves those
two pages on chips with LPS PG. That leaves 5 pages for the beacon next
to a station on 8723d, i.e. up to 600 bytes, and changes nothing for
8822c.

Before sending v2 I will repeat your check on my RTL8723DE: grow the
beacon past 216 bytes with vendor_elements in hostapd and confirm there
is no "rsvd page over size" and the beacon is actually transmitted.

Ping-Ke, does that approach look acceptable to you, or would you prefer
to keep the combination limited to 8822c?

Best regards,
Carl