Linux wireless drivers development
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC v2] mac80211: stop tx before doing hw config and rate update
Date: Mon, 29 Aug 2011 17:18:29 +0200	[thread overview]
Message-ID: <1314631109.8959.20.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <1314617635-27936-1-git-send-email-rmanohar@qca.qualcomm.com>

On Mon, 2011-08-29 at 17:03 +0530, Rajkumar Manoharan wrote:
> 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@qca.qualcomm.com>
> ---
> 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);

doesn't that also need synchronize_net()?

johannes


  reply	other threads:[~2011-08-29 15:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-29 11:33 [RFC v2] mac80211: stop tx before doing hw config and rate update Rajkumar Manoharan
2011-08-29 15:18 ` Johannes Berg [this message]
2011-08-29 15:39 ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1314631109.8959.20.camel@jlt3.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=rmanohar@qca.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox