RE: [PATCH rtw-next v3 3/3] wifi: rtl8xxxu: preserve RX requests across recoverable transfer errors

[Ping-Ke Shih <pkshih@realtek.com>]

Kim Wooseok <5mghybrid@khu.ac.kr> wrote:
> > Not prefer using bare system_wq.
> > Can both use schedule_delayed_work()?
> 
> In v3, the error path uses queue_delayed_work(system_wq, ..., delay),
> while normal completions use mod_delayed_work(system_wq, ..., 0).
> 
> I can replace the error-path call with schedule_delayed_work().
> However, the normal-completion path is intended to bring an existing
> delayed retry forward when the pending count exceeds the batching
> threshold, which schedule_delayed_work(..., 0) cannot do because it
> leaves an already pending timer unchanged.

I knew this point. Does it matter to schedule a normal case immediately
after an error case (defer to schedule) happened within 100ms?
(Just an open question)

> 
> Would it be OK to retain mod_delayed_work() for normal completions,
> changing its queue argument to system_percpu_wq?

OK if above question is yes. 

Or both change to use mod_delayed_work()?

> 
> With that change, schedule_delayed_work() would select system_percpu_wq
> internally, and mod_delayed_work() would use the same queue explicitly.
>