Not all NSS / MCS / channel bandwidth combinations are valid.
This will be important for rate control and transmit rate
setup (eg static management, unicast, multicast rates.)
This is based on 802.11-2020 Section 21.5 (Parameters for VHT-MCSs.)
Details
Details
- Reviewers
bz - Group Reviewers
wireless - Commits
- rG1568caaf5721: net80211: add valid VHT MCS combinations and helper functions
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 62052 Build 58936: arc lint + arc unit
Event Timeline
Comment Actions
I am fine with this either way. If you don't want to change this is accepted too.
| sys/net80211/ieee80211_phy.c | ||
|---|---|---|
| 680 | Surprised you don't use a default here for future-proof-ness. | |
| sys/net80211/ieee80211_phy.c | ||
|---|---|---|
| 680 | I want the compiler to complain, it's an enum, right? :) | |
| sys/net80211/ieee80211_phy.c | ||
|---|---|---|
| 680 | Do you ever expect more supported bw in VHT? Fine by me either way. | |
Comment Actions
Not for VHT, but who knows what we'll end up doing for EHT/HE, what we want to do for half/quarter rates, etc.
Right now ni_chw is the protocol width in the IE, not specifically whatever the PHY is configured as. All kinds of fun stuff may happen in the future!