Re: rework on .flush() callback

["Arend van Spriel" <arend@broadcom.com>]

On 11/16/2012 02:34 PM, Johannes Berg wrote:
>> The problem here is that in brcmsmac the flush does the
>> >ieee80211_wake_queues() call, because that could also wakeup the netif
>> >queues. So doing it in the driver seems a bad idea. Any suggestion on
>> >how to solve this?
> Yeah so .. I actually thought about this at some point, it's tricky. For
> the global queues we check what reasons we had for stopping them, but we
> don't do that for the netif queues. Maybe we should? I also think flush
> should at least have the option to be per queue, so that we could do
> something per sdata in mac80211 if the driver uses different HW queues
> for different interfaces.

To me so from driver perspective, it was not clear what 
ieee80211_stop/wake_queues was operating on. Somehow the knowledge that 
the netif queues are already stopped upon calling 
ieee80211_stop_queues() should be retained.

Regarding the flush do you mean flush per queue or flush per vif? Per 
vif could have its perks, I guess.

> However, I'm not sure I'll have time to work on corner cases with
> software scanning since we don't use that. I might work on the flush
> thing though, that could be interesting.

ok. The drv_flush() call is done in several places so not only scanning. 
All with the drop flag set to false. Is that just to be prepared or do 
you foresee an actual use-case?

Gr. AvS