Hi Kalle, > -----Original Message----- > From: Kalle Valo [mailto:kvalo@xxxxxxxxxxxxxx] > Sent: Thursday, January 25, 2018 6:29 PM > To: Ganapathi Bhat > Cc: linux-wireless@xxxxxxxxxxxxxxx; 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 <gbhat@xxxxxxxxxxx> writes: > > >> > 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 <cluo@xxxxxxxxxxx> > >> > Signed-off-by: Ganapathi Bhat <gbhat@xxxxxxxxxxx> > >> > >> 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
