RE: [PATCH v8 6/6] wifi: rtw88: sdio: add TX back-pressure and retry on page starvation

[Ping-Ke Shih]

Luka Gejak <luka.gejak@xxxxxxxxx> wrote:
> Hi Ping-Ke,
> 
> On August 28, 2026 11:29:29 AM GMT+02:00, Ping-Ke Shih <pkshih@xxxxxxxxxxx> wrote:
> 
> > At the last review (I think v9), I will focus on the changes of this
> > patchset doesn't affect existing chips.
> 
> That is the right thing to focus on and it is the part I cannot test, so
> let me set out what the other parts actually run, and correct something
> in the v8 cover letter while I am at it.
> 
> New code that is not behind rtw_is_8723bs(), all of it structural:
> 
>   sdio.h                   struct delayed_work work
>   rtw_sdio_init_tx()       INIT_DELAYED_WORK(), mutex_init(), and
>                            mutex_destroy() on its error path
>   rtw_sdio_tx_kick_off()   mod_delayed_work(..., 0) in place of
>                            queue_work()
>   rtw_sdio_deinit_tx()     cancel_delayed_work_sync(), mutex_destroy()
> 
> Only this chip ever arms a delay, so on the other parts the work is
> still queued immediately, and only this chip ever takes the mutex.
> 
> Two existing functions were also restructured and every chip runs
> through them, so I should not describe the above as the whole story.
> rtw_sdio_process_tx_queue() now returns a value instead of void, and
> rtw_sdio_tx_handler() uses it. The behaviour is meant to be identical
> for the other parts: on an empty queue the new "if (ret > 0) break"
> takes the place of the old skb_queue_empty() break, and on a failed
> write the frame is still requeued and the loop still retries, since
> rtw_sdio_8723bs_reschedule_tx() returns false for anything that is not
> this chip. That is the piece I would most like you to check.

Thanks for the info. For me, I'd check actual patch content in case
something is not expected. That means if you can elaborate patches
without string unnecessary part (something like moving a chunk to
another place to help 'git diff' to generate the patch. This is only
a practice, but I don't specifically point to somewhere your patches
need the changes), it will be helpful to review whether this patchset
affects existing chips.