On Sun, 2010-01-10 at 14:35 +0100, Michael Buesch wrote: > On Sunday 10 January 2010 14:07:53 Lennert Buytenhek wrote: > > Since commit "mwl8k: handle station database update for AP's sta > entry > > via ->sta_notify()", mwl8k every now and then gets a command timeout > > when ifconfig'ing a STA interface down. This turns out to be due to > > mwl8k_stop() being called while the work queue item that was > scheduled > > by mwl8k_sta_notify() to remove the STA entry for the associated AP > is > > still queued, and the former disables interrupts so that when the > > latter eventually runs, a command completion interrupt is never > seen. > > > > Fix this by changing ieee80211_stop_device() so that the workqueue > is > > flushed before drv_stop() is called, instead of doing it the other > way > > around as is done now. (As ->stop() is allowed to sleep, there > isn't > > any reason for drivers to queue work from within it.) > > This smells like we should either: > o Add an assertion that checks whether the driver queued work although > it was forbidden. > or > o Call flush_workqueue twice. Once before and once after drv_stop. I don't think we need to do either. See, it's not strictly forbidden to queue work, there's just no guarantee when it will be executed. But since the driver is already stopped, what kind of guarantee should it get anyway? And destroying the workqueue will flush it anyway, if this is part of the unregistration procedure. So, the driver would be stupid to queue work there that did anything to the hw, but if it has some work that's purely software state it shouldn't matter at all. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
