Ganapathi Bhat [off-list ref] writes:

quoted

quoted

The above scenario occurs in some platforms where the RX processing is
comparitively slower. This results in RX stall in driver, command/TX
timeouts in firmware. The above scenario is introduced after commit
c7dbdcb2a4e1
("mwifiex: schedule rx_work on RX interrupt for USB")

To fix this set a new more_rx_task_flag whenever RX data callback is
trying to schedule rx_work but rx_processing is not yet cleared. This
will let the current rx_work(which was waiting for
rx_proc_lock) to loopback and process newly arrived RX packets.

Signed-off-by: Cathy Luo <redacted>
Signed-off-by: Ganapathi Bhat <redacted>

I can't find any commit with id c7dbdcb2a4e1, is it correct?

Correct. Actually the commit id c7dbdcb2a4e1 is the PATCH [1/2] sent in this series.

Actually the commit id will be different, I just tested it to be sure:

$ git reset --hard master
HEAD is now at b69c1df47281 brcmfmac: separate firmware errors from i/o errors
$ git am -s -3 1.patch
Applying: mwifiex: schedule rx_work on RX interrupt for USB
$ git log --oneline -1 | cat
676bc4833907 mwifiex: schedule rx_work on RX interrupt for USB
$ git reset --hard master
HEAD is now at b69c1df47281 brcmfmac: separate firmware errors from i/o errors
$ git am -s -3 1.patch
Applying: mwifiex: schedule rx_work on RX interrupt for USB
$ git log --oneline -1 | cat
74c5fc1d45b4 mwifiex: schedule rx_work on RX interrupt for USB
$ 

So the date, and most likely also the commiter, is included when
calculating the hash. So you can't really refer to uncommited patches
using a commit id as the id is determined only once the maintainer
applies the patch.

-- 
Kalle Valo