RE: [PATCH v3 0/5] wifi: rtw88: preparations for RTL8723B/RTL8723BS

On August 12, 2026 2:38:23 AM GMT+02:00, Ping-Ke Shih <[email protected]> wrote:
>
>Luka Gejak <[email protected]> wroet:
>> On August 4, 2026 8:54:20 AM GMT+02:00, [email protected] wrote:
>> >From: Luka Gejak <[email protected]>
>> >
>> >This is the first of two series adding support for the Realtek RTL8723B
>> >802.11n chipset and its RTL8723BS SDIO variant to rtw88. It contains
>> >only the changes to the shared rtw88 core that the chip driver depends
>> >on. The chip itself, the build glue and the MAINTAINERS entry are a
>> >second series.
>> >
>> >v1 had 19 patches, v2 had 11, this has 5.
>> >
>> 
>> ...
>> 
>> Hi Ping-Ke,
>> 
>> I have sent a v4 that supersedes this series, before you review v3, so
>> you do not spend time on this one. As you suggested, I am noting it here
>> on the v3 cover.
>
>Thanks for the notification, and sorry for the late. I hope I can review
>v4 this Friday if no urgent tasks interrupt me.
>

No need to apologise. Before you spend time on it: please skip patch 4/7
("fw: handle the RTL8723BS management TX reports"). I am dropping it in
v5. Your question below is what sent me back to the hardware, and the
answer is that the patch cannot be doing what its commit message claims.

>> 
>> v4 re-adds two patches that were dropped in v2, both on the TX report and
>> leave-LPS paths. Testing on slower ARM SDIO hosts, Peter Robinson on the
>> RFC and another tester on a Rockchip RK3288 board, reproduced "failed to
>> get tx report from firmware"
>
>This makes sense for slower platform.
>
>> and "firmware failed to leave lps state",
>
>Does this only occur on "slow" platform? Unless a C2H event was handled
>slowly? I'll review the patch and add comment there.
>
>Ping-Ke
>

It is not a C2H handling issue on this chip, and that is the problem with
the patch. The RTL8723BS v41 firmware does not advertise
FW_FEATURE_LPS_C2H: the feature word in the firmware header is 0x00007df0,
which has FW_FEATURE_SIG clear, so __update_firmware_feature() sets
fw->feature to 0. rtw_fw_leave_lps_check() therefore takes the
__rtw_fw_leave_lps_check_reg() branch and polls REG_TCR. Nothing ever
waits on rtwdev->lps_leave_check, so the part of my patch that stops
completing it on a 0x32 event changes nothing at all.

The other half does not hold up either. With the driver instrumented, 93
TX reports over three scans arrive as C2H id 0x03, and no event arrives
with a top level id of 0x12 or 0x32. Bitterblue Smith made this point on
v1, that 0x12 and 0x32 are payload bytes of C2H_CCX_TX_RPT rather than
C2H ids. The hardware agrees with him.

The tester's report does not require the patch either. He saw "failed to
get tx report from firmware" easily on the unfixed branch, and "firmware
failed to leave lps state" only sometimes; with both patches applied the
lps warning did not appear. An intermittent warning not appearing in one
run does not establish much on its own.

So that warning is still unexplained. Since the check is a REG_TCR poll
with a 100 ms budget, a slow SDIO host missing that window is the obvious
candidate, but I have not reproduced it: my only board is a fast x86
host. A branch carrying patch 3 alone is out with the tester now. If a
poll window turns out to be the cause I will send it as a separate patch,
with the measurement behind it, rather than folded into this one.

One detail from the same report that is worth separating out: with both
patches applied, the tx report warning still returns after a
"systemctl restart [email protected]". That looks like the
generic case where a management frame is still awaiting a report when the
link tears down, since the tx_report queue is only purged at deinit and
not on disconnect. That is not specific to this chip and I am not
addressing it in this series.

So the slow host improvement in v4 comes from patch 3 alone. It extends
the 2500 ms timeout from commit c80788f7c5ae ("wifi: rtw88: increase TX
report timeout to fix race condition"), which you acked for the
RTL8723DU, to the RTL8723BS for the same off channel scan race, and the
slow host reports match that mechanism. v5 will be this series with
patch 4 removed, so six patches, and the cover letter will say that one
patch was restored rather than two.

Best regards,
Luka Gejak