On 31 May 2011 14:35, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > Looks like I completely missed this since you hid it in an ath9k > patchset. DON'T DO THAT. > > Anyway, John, please revert. This is completely useless. Not only is > abusing the CSA stop reason a show-stopper, the whole patch is also just > not right, it seems like a workaround around a rate control algorithm > that isn't able to do an atomic HT change by itself. Also, it won't even > do what you want, there may be packets being processed concurrently > while stopping the queue -- calling stop_queues() is no guarantee that > no packet will be processed afterwards. I'm unsure of what's going on in mac80211 and ath9k here. FreeBSD handles it very simply - it goes via ath_reset() which drains each TX queue, freeing existing packets. Inefficient (ie, packet loss) but fine for now. How is ath9k handling the situation where the hardware currently has HT40 packets queued in the TX queues and you do a 40->20 change? The 40->20 change in the ath9k instance requires reinit'ing of the card. What happens to currently queued packets? Adrian -- 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
