All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Cc: John Linville <linville@tuxdriver.com>, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 2/4] mac80211: remove channel type argument from rate_update
Date: Fri, 30 Mar 2012 08:46:39 +0200	[thread overview]
Message-ID: <1333089999.3908.4.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <20341.14488.303053.16407@gargle.gargle.HOWL>

On Fri, 2012-03-30 at 10:07 +0530, Sujith Manoharan wrote:
> Johannes Berg wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> > 
> > The channel type argument to the rate_update()
> > callback isn't really the correct way to give
> > the rate control algorithm about the desired
> > RX bandwidth of the peer.
> > 
> > Remove this argument, and instead update the
> > STA capabilities with 20/40 appropriately. The
> > SMPS update done by this callback works in the
> > same way, so this makes the callback cleaner.
> 
> I think that the HT capabilities cannot be changed dynamically.
> The HT operating parameters along with ChannelSwitch frames are used to
> notify bandwidth changes. Or that is my understanding of 11.14.4.2.

Yes, that's true. However, we use the sta.ht_cap field more of a current
operating set database. For example, we also update it when the station
changes SMPS configuration. Also, we never keep it at just the station's
capabilities -- we always restrict it by our own TX capabilities (so if
for example we aren't 40 MHz capable, we already don't leave 40 MHz in).

Overall, I don't really see a problem with this. I suppose we could
rename the field to make that a bit clearer, but I see little value in
using some other struct or so?

johannes


  reply	other threads:[~2012-03-30  6:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-28  8:58 [PATCH 0/4] early HT channel setting Johannes Berg
2012-03-28  8:58 ` [PATCH 1/4] mac80211: set HT channel before association Johannes Berg
2012-03-28  8:58 ` [PATCH 2/4] mac80211: remove channel type argument from rate_update Johannes Berg
2012-03-30  4:37   ` Sujith Manoharan
2012-03-30  6:46     ` Johannes Berg [this message]
2012-03-30  7:12       ` Sujith Manoharan
2012-03-28  8:58 ` [PATCH 3/4] mac80211: remove queue stop on rate control update Johannes Berg
2012-03-28  8:58 ` [PATCH 4/4] mac80211: notify driver of rate control updates Johannes Berg
2012-03-29 19:13   ` Eliad Peller
2012-03-29 19:14     ` Johannes Berg
2012-03-30  6:43   ` [PATCH 4/4 v2] " 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=1333089999.3908.4.camel@jlt3.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=c_manoha@qca.qualcomm.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.