Luka Gejak <luka.gejak@linux.dev> wrote:
> On August 22, 2026 6:51:59 PM GMT+02:00, Luka Gejak <luka.gejak@linux.dev> wrote:
> >On August 20, 2026 11:04:06 AM GMT+02:00, luka.gejak@linux.dev wrote:
> >>From: Luka Gejak <luka.gejak@linux.dev>
> >>
> >>This is the first of two series adding support for the Realtek RTL8723B
> 
> ...
> 
> >Nothing in this series changes. The rate is about one in 9200 wakes.
> >
> >Best regards,
> >Luka Gejak
> 
> Follow up to the previous email:
> 
> The soak has run on since that mail. Over 110557 wakes there is now one
> poll 3, still no poll 4, and four failures:
> 
>         poll0=158 poll1=110557 poll2=35 poll3=1 poll4=0 fails=4

Is this distribution of polling times?
Does it mean 4 instances over 4 times of polling?

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.

More, it is worth to try disable_lps_deep=y.

> 
> So failures outnumber poll 3 successes, which makes the point stronger,
> not weaker. The rate is about 1 in 27600 wakes rather than the 1 in
> 9200, which I quoted from the smaller sample.

On August 25, 2026 9:08:02 AM GMT+02:00, Ping-Ke Shih <pkshih@realtek.com> 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