On Saturday 02 June 2007 15:17:55 Olivier Cornu wrote: > 2007/6/1, Michael Buesch <mb@xxxxxxxxx>: > > On Friday 01 June 2007 23:00:16 Olivier Cornu wrote: > > > The only call to ieee80211_stop_queue() grep can find is in > > > bcm43xx_dma.c:1171, i.e. bcm43xx_dma_tx(). And bcm43xx_dma_tx() is > > > only called from bcm43xx_tx(). > > > What did i miss? > > > > Periodic work. I removed that in my current tree. > > And I think we also call it when resetting the device. But I'm not sure. We also call it for a device reset. Which is required for a band switch (in certain cases), for example. Also for other things. > I guess i see why we did not understand each other: these are calls to > ieee80211_stop_queues, not directly to ieee80211_stop_queue (even > though stop_queues ultimately calls stop_queue). > The difference is relevant because, if some kind of locking (for > example) was needed in the special contexts stop_queues only might be > called from, these locks would be held inside stop_queues, around its > stop_queue calls. :) Ok, I see. stop_queues should take the locks etc.. so that there's no deadlock. > Is there any way to tell mac80211 the device is in a [temporary] > "non-functional" state (reset, association loss...) ? As far as I can see ieee80211_stop_queues() is exactly for that, but it's broken. In the tx handler, where it should be safe to call, it's useless to call stop_queues(). -- Greetings Michael. - 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
