RE: [PATCH v7 0/6] wifi: rtw88: preparations for RTL8723B/RTL8723BS
Luka Gejak <[email protected]>
| Newsgroups | org.kernel.vger.linux-wireless,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On August 25, 2026 9:08:02 AM GMT+02:00, Ping-Ke Shih <[email protected]> wrote: > Is this distribution of polling times? > Does it mean 4 instances over 4 times of polling? My fault for not explaining it. pollN counts wakes that finished on the Nth read of REG_TCR, so poll1 needed one 20 ms sleep. fails counts the ones still set after all five. So poll4=0 with fails=4 means nothing ever succeeded on the last poll, yet four gave up completely. A budget that was merely too small should taper instead. The patch also keeps polling for another 500 ms and the bit was still set in all four. > One reason the firmware can't leave LPS properly is that some packets > are still in hardware queue, so this might be highly related to > environment. That fits better than anything I had, since it explains why it is either quick or never. I will dump the queue lengths, REG_SDIO_FREE_TXPG and REG_SDIO_OQT_FREE_PG at the failure and report back. > More, it is worth to try disable_lps_deep=y. Already off here, twice over: rtw8723b_hw_spec has .lps_deep_mode_supported = 0 like rtw8723d and rtw8703b, and this firmware reports no feature bits, so rtw_update_lps_deep_mode() returns LPS_DEEP_MODE_NONE either way. Best regards, Luka Gejak