wifi: rtw88: 8723d: add iface combination

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.

---

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(-)

index 0f23498..c64a3ba 100644
@@ -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

Hi Carl,

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

Hi Luka,

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

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.

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

As you confirmed RTL8723DE work well, it is okay to me.

Did you setup an air sniffer to capture packets? I suggest you can have one to check AP behavior including:
1. The beacon is sending on time. (100TU)
2. Is the behavior expected with DTIM=3 ?
3. When connected station goes sleep and AP send a packet to the station, the corresponding TIM bit is set?
4. broadcast/multicast is sent right after beacon (by ATIM window register)
5. Combine 2 and 4, checking corresponding TIM bit is set?

Ping-Ke

Hi Ping-Ke,

Thanks for the review.

No, I have not. I only have this one RTL8723DE laptop and no second Wi-Fi adapter that can capture in monitor mode, so I cannot check the five points you listed over the air (beacon interval, DTIM behavior, the TIM bit for a sleeping station, and broadcast/multicast after the beacon).

What I did test on the RTL8723DE (kernel 7.2.5, hostapd 2.12, station and AP on 2.4 GHz channel 1):

- With v1, the AP served a phone beside the station for about four hours, and the station re-associated within one second each of four times I disconnected it with the AP running.
- With the LPS PG patch, beacons of 192, 312 and 592 bytes were built and downloaded without any "rsvd page over size" error (a 312 byte beacon failed without it), and a 639 byte beacon was still rejected, as calculated.

That last test only shows that the driver builds and downloads the beacon. It does not show what is transmitted over the air.

Would you be fine with sending v2 as it is, with the commit message stating exactly what was and was not tested? Or would you rather wait until someone with a sniffer can run your checks? If there is a way to check any of those points with a single adapter, I am happy to try it.

Best regards,
Carl

With your tests from user point of view, I think it is okay. That'd be good if someone can capture a sniffer and analyze it, but that isn't a blocking item to merge this patch. Please follow Luka's suggestions to spin v2.

I think no. Driver isn't aware that packets sent by firmware/hardware.

Ping-Ke

I can test v2 on rtl8723du and another card as a sniffer if that helps :)