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

Kim Wooseok [off-list ref] wrote:

quoted

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.