This is now in -HEAD.


On 30 June 2013 20:13, Adrian Chadd <> wrote:
> Hi all,
> As part of adding 11n awareness to various parts of net80211 (TDMA,
> 802.11s code, implementing AMSDU, 11n+fast-frames support, TX rate
> control) the PHY table code needs to be taught about said rates.
> Unfortunately the PHY code as it stands only knows about non-11n
> stuff. To add to the pain, the basic rate bit (0x80) is the same as
> the MCS rate bit (0x80). They're supposed to not be used in
> overlapping contexts but in some places (notable ni->tx_rate, for
> example!) they are. In this code, the rate code -> table index code
> makes the unfortunate mistake of also indexing things with the basic
> rate bit set, which messes up MCS rates.
> The "real" solution is to make the basic rate and mcs rate bits either
> much higher bits, or to turn the rate representation into a struct
> with the rate code / speed and PHY bits (eg, BASIC, MCS, etc). That's
> a big change that touches a _lot_ of code so I'm not yet willing to go
> and do all that work. It's likely I'm going to have to for 802.11ac
> support however. Sniffle.
> The "real real" solution is to not use this rate table index thing
> outside of a very specific set of instances. I can unfortunately see a
> million little race conditions here where the driver holds onto a rate
> table index whilst doing something, whilst some other part of the code
> decides to wholesale change said rate table underneath it. it's
> terrifying; I may end up having to do a further pass and kill this
> whole "use the rate table index" thing outside of contexts that I can
> protect things with locks.
> So, here's what I've done:
> * Make the current PHY and rate table lookup routines non-11n only. If
> the BASIC bit is set (0x80) then it panics.
> * Add the 11n rates into the PHY tables
> * Add some accessor methods to do the ratecode->rateindex lookup
> rather than manually going grubbing around in ieee80211com.
> * Modify callers of the ratecode->rateindex routines to strip the
> basic bit if it's set. They all assume it's legacy at this point, so
> it's fine.
> I've tested this on ath (where it should be a no-op) and iwn (where it
> does use the PHY table and rate control code.) So far, so good. I
> haven't sat down and fully debugged whether populating the 11n rate
> table with 11n rates is causing confusion in the iwn code - the iwn
> code does some magic crap somewhere to "pretend" the rates are non-11n
> when they indeed are, so the rate control code can do it's thing. i'd
> obviously like to kill _that_.
> The patch is here:
> Please give it a whirl. It's only really going to show up if your
> device uses the net80211 rate control code. As it patches ral and iwn,
> I'm doubly interested in those devices.
> I'd like to commit this in a couple of days and start working on
> undoing the brain damage in iwn so the rate control modules can
> actually do 11n rate table lookups.
> Thanks!
> -adrian
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to