Hi Arend, > The brcmsmac driver still faces a lot of bug reports related to the > .flush() callback (see [1] from Dave Jones). > > Previously I had looked into this and found that during the flush the > .tx callback still gets new frames. So I put ieee80211_stop_queues() in > the flush and upon exit call ieee80211_wake_queues(). Due to issues > still persisting we went a bit deeper in mac80211. > > It turns out that mac80211 stops the netif queues for each interface > (except monitor iftype) and not the internal queues during a scan. So it > stops the netif queues, calls the flush(), and upon returning to the > associated channel it wakes up the netif queues. Hmm, interesting. Yeah this is for scanning, that software scan stuff is a bit buggy in this area, I agree. This only really works if there's nothing on the internal queues, otherwise during flush the driver will wake the queues and get more packets etc... > 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. 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. johannes -- 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
