On Thu, Jan 25, 2018 at 07:10:52AM +0000, Kalle Valo wrote: > Ganapathi Bhat <[email protected]> wrote: > > > From: Shrenik Shikhare <[email protected]> > > > > There is race for data_received flag between main thread and > > RX data interrupt(mwifiex_usb_rx_complete()): > > 1. USB received an RX data interrupt, set data_received flag > > 2. main thread checks data_received, if set queues rx_work > > 3. rx worker thread independently start processing rx_data_q > > 4. rx work exits (once rx_data_q is empty) > > 5. main thread resets the data_received flag(after #2) > > 6. Now at the corner case there will be high RX data interrupts > > between #4 and #5 > > 7. Driver stops submitting URBs to firmware, once rx_pending > > exceeds HIGH_RX_PENDING > > 8. The flag data_received(cleared in #5) will remain unset since > > there will be no interrupts from firmware to set it(after #7) > > > > Above scenario causes RX stall in driver, which will finally > > result in command/TX timeouts in firmware. > > > > As a fix, queue rx_work directly in mwifiex_usb_rx_complete() > > callback, instead in the main thread. This removes dependency > > of RX processing on data_received flag. > > > > Signed-off-by: Cathy Luo <[email protected]> > > Signed-off-by: Ganapathi Bhat <[email protected]> > > Brian, did you have a chance to review these two?
Not really. I don't generally make a lot of time to review the USB driver unless it's really screwing around with the main driver, since I don't use the USB driver. But I'll try to give it a few glances.
