The assumption is that during the hw config, transmission was already stopped by mac80211. But during channel type change, the mac80211 continue to transmit frames. The driver like ath9k does chip reset while doing channel set. This could leads to buffer overflow at driver side. And also after configuring the channel and before doing rate updation, the frames are continued to xmit with older rates. This patch ensures that the frames are always xmitted with updated rates and avoid buffer overflow. Signed-off-by: Rajkumar Manoharan <rmanohar@xxxxxxxxxxxxxxxx> --- v2: Removed new stop queue reason code by netif net/mac80211/mlme.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 60a6f27..a1deb33 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -232,6 +232,9 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata, WARN_ON(!ieee80211_set_channel_type(local, sdata, channel_type)); } + netif_tx_stop_all_queues(sdata->dev); + + drv_flush(local, false); /* channel_type change automatically detected */ ieee80211_hw_config(local, 0); @@ -245,6 +248,8 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata, rcu_read_unlock(); } + netif_tx_wake_all_queues(sdata->dev); + ht_opmode = le16_to_cpu(hti->operation_mode); /* if bss configuration changed store the new one */ -- 1.7.6.1 -- 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
