Hi Kalle,

-----Original Message-----
From: Kalle Valo [mailto:kvalo@codeaurora.org]
Sent: Thursday, January 25, 2018 6:29 PM
To: Ganapathi Bhat
Cc: linux-wireless@vger.kernel.org; Brian Norris; Cathy Luo; Xinming Hu;
Zhiyuan Yang; James Cao; Mangesh Malusare; Shrenik Shikhare
Subject: Re: [EXT] Re: [2/2] mwifiex: use more_rx_task_flag to avoid USB RX
stall

Ganapathi Bhat [off-list ref] writes:

quoted

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.

Ok. So, what can be done in this case. Should we wait for 1st patch to be committed and then send v3 of second patch?

--
Kalle Valo

Regards,
Ganapathi