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

["Luka Gejak" <luka.gejak@linux.dev>]

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