On Fri, Nov 16, 2012 at 04:02:30PM +0100, Arend van Spriel wrote: > On 11/16/2012 03:12 PM, Seth Forshee wrote: > >What does strike me as problematic is the locking in brcms_ops_flush(). > >It holds wl->lock, and the interrupt handling tries to acquire the same > >lock. Doesn't this prevent both the txpktpend counts from getting > >updated and any more packets being transmitted from the packet queue? > > > >Seth > > > > Actually, in the brcms_c_wait_for_tx_completion() the while loop > does a brcms_msleep() which releases the wl->lock, does an msleep() > and acquires the lock. At least that is what is currently in > wireless-testing. I changed it internally to wait_for_event() > mechanism, but it was not accepted as people still were seeing > issues. Ah, I failed to look at what brcms_msleep() is doing so I didn't notice that. Nevermind then. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
