Re: [PATCH v7 0/6] wifi: rtw88: preparations for RTL8723B/RTL8723BS

On August 20, 2026 11:04:06 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.
>

...

>Known limitation
>================
>
>After a long idle period the firmware intermittently fails to leave LPS,
>which rtw88 reports as "firmware failed to leave lps state". That check
>is the REG_TCR poll in __rtw_fw_leave_lps_check_reg(). On one occurrence
>here the warning was followed fourteen seconds later by a full
>reauthentication, so it is not only log noise.
>
>Power save is enabled on my test machine and it reproduces there,
>roughly once per day of mostly idle uptime, and the occurrences cluster.
>It was first reported on ARM SDIO boards, but it is not specific to slow
>hosts.
>
>Instrumenting the poll shows the wake is never immediate on this board.
>Over a run of a hundred consecutive wakes the bit was still set on the
>first read every time and cleared on the next 20 ms poll; logging only
>the outliers after that, the occasional wake takes two polls. So the
>budget is five polls and the ordinary cost is one, which also means
>every wake costs at least 20 ms here. A failure is then the far tail of
>that distribution, which leaves open whether the budget is simply too
>small. I would rather keep measuring than guess at a fix.
>
>It is not caused by anything in this series, and it needs the chip
>driver from the second series to be reachable at all, but it is open and
>I am chasing it.
>

...
Hi Ping-Ke,

A correction to the "Known limitation" section of the cover letter. I wrote
that a failure looks like the far tail of the wake time distribution,
leaving open whether the poll budget is too small. I have since debugged it
and that turns out not to be the case.

With a local debug patch logging REG_TCR on every poll of
__rtw_fw_leave_lps_check_reg(), I caught three failures. In every one
BIT_PWRMGT_HWDATA_EN was still set after 600 ms, six times the budget. And
there is no tail. Counting how many polls each successful wake needed, at
the third failure:

        poll0=25 poll1=27610 poll2=9 poll3=0 poll4=0 fails=3

No wake in roughly 27600 ever took three or four polls, yet failures happen.
The firmware either finishes within 40 ms or not at all.

A larger LEAVE_LPS_TRY_CNT would not help. This is firmware side, and the
existing code already does the sensible thing: give up, clear the bit, warn.
Nothing in this series changes. The rate is about one in 9200 wakes.

Best regards,
Luka Gejak