The summary:
- Refactor ni_txrate access into ieee80211_node_get_txrate_dot11rate() and ieee80211_node_set_txrate_dot11rate(). These wrap the ni->ni_txrate access and will eventually be able to do runtime sanity checks and fallback where necessary.
- Refactor ieee80211_node_get_txrate_mbit() from the ioctl code which sets isi_txmbps (which is in 0.5mbit units.)
- Also use ieee80211_node_get_txrate_mbit() in various places in the code where the dot11rate was turned into a Mb value, which was very wrong for HT (but also only used for logging, so it didn't have an effect on normal runtime.)
The long version:
The current ni->ni_txrate value is what net80211's phy code
calls a 'dot11rate'. Inside the ieee80211_phy.c tables you'll
find a bunch of tables which represent:
- for legacy rates its in 1/2 mbit units.
- for turbo (Atheros 40MHz OFDM) it's the non-turbo rates, but the turbo rate speed in kbit/sec.
- for 802.11n rates its the MCS, starting at 0x80.
However there are a couple of catches with this:
- Basic rates are represented in the pre-11n rates using the high bit (IEEE80211_RATE_BASIC)
- 11n rates are also represented using the high bit (IEEE80211_RATE_MCS)
Now, ni->ni_txrate will clear the IEEE80211_RATE_BASIC flag before
storing it, so if the high bit exists it must be an 802.11n rate.
However, there's still a bunch of code everywhere that purposefully
filters that out.
The goals of this commit:
- Provide an easy API to migrate existing drivers and other consumers to - ieee80211_node_get_txrate_dot11rate() is defined as "will return the normal legacy or HT rate" so all the existing code can work.
- Lay the ground work for extending ni_txrate (and a rate representation in general) that can represent legacy, HT, VHT, EHT, HE, etc rates.
- Create a central place where ni_txrate is updated from rate control, drivers that will update ni_txrate itself, and consumers, so we can provide some basic runtime checks / logging as VHT, EHT, HE, etc rates are eventually added.
For example, a VHT driver will eventually receive VHT rates, but an
existing HT driver will not, so the API should log and return a
sensible default when something like a VHT rate shows up on a HT only
device.
The rate control code currently returns a rix, and sets ni_txrate to the
dot11rate. Drivers can choose either. However, choosing the rix is
risky because you need to know if it's the ni_rates or ni_htrates, which
requires a lot of duplicate work that lines up consistently at all
layers (see the AMRR code for an example.)