Hi Brian, > -----Original Message----- > From: Ganapathi Bhat > Sent: Tuesday, January 30, 2018 8:55 PM > To: 'Brian Norris' > Cc: Kalle Valo; linux-wireless@xxxxxxxxxxxxxxx; 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 > > Hi Brian, > > > -----Original Message----- > > From: Brian Norris [mailto:briannorris@xxxxxxxxxxxx] > > Sent: Tuesday, January 30, 2018 3:38 AM > > To: Ganapathi Bhat > > Cc: Kalle Valo; linux-wireless@xxxxxxxxxxxxxxx; 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 > > > > Hi, > > > > On Sun, Jan 28, 2018 at 11:19 PM, Ganapathi Bhat <gbhat@xxxxxxxxxxx> > > wrote: > > >> From: Ganapathi Bhat > > >> > From: Brian Norris [mailto:briannorris@xxxxxxxxxxxx] On Thu, Jan > > >> > 25, 2018 at 09:59:04AM +0000, Ganapathi Bhat wrote: > > >> > > > 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. > > >> > > > >> > What? Why would you introduce a bug and only fix it in the next > patch? > > >> With the first patch the original issue took considerably longer > > >> time to recreate. Also it followed a different path to get > > >> recreated(shared in commit message). > > >> > Does that mean you should just combine the two? > > >> Let us know if that is fine to merge them. We can modify the commit > > >> message accordingly. > > >> > Or reverse the order, if patch 2 doesn't cause problems on its own? > > >> Patch 2 has a dependency on patch 1. > > > One correction. There is no commit dependency between patch 1 and > > 2(they can be applied in any order). But the result would be same. We > > need both fixes. Let us know if we can combine them. > > > > I haven't closely looked at patch 2 yet. My only statement was that it > > makes no sense to have 2 commits, with the second one labeled as > > "Fixing" the first one. From your descriptions, it sounds like patch 2 > > should actually come first, > Ok. I understand. I will reorder them and send v3(along with spinlock > change). I was trying to reorder the patch but found patch 2 is indeed dependent on patch 1. Consider the first point in commit message of patch 2: 1. USB receives an RX data interrupt, queues rx_work This is the change added in patch 1. Earlier on receive of RX data interrupt, driver would queue main_work, which in turn queued rx_work. But after patch 1 driver tries to queue rx_work in interrupt context. Let us please know your thoughts on this. > > but I'm not really sure. I only looked far enough to say that I didn't > > like patch > > 1 as-is :) > > > > Brian > Regards, > Ganapathi
