Use the new net80211 routines rather than rolling our own.
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 60777 Build 57661: arc lint + arc unit
Event Timeline
looking at these, i'm wondering whether the better move is to be doing the channel check inside the helper functions as well. i remember the node channel being .. weirdly sketchy thought. i'll go do some more deep diving on this before it lands.
Let us know when you come to the final conclusion and we can do the review then; I'd rather do it once than thrice.
ah I remember it now. ni->ni_chw has to do with the currently configured channel width, which can be changed via a HT_TXCHWIDTH action frame. The STA can request that the AP switch to 20MHz for transmitting to that station for now, even if the station is associated in 40MHz.
So when it's associated, ni_chw == the width of ni->ni_chan.
I think I'm going to add another helper function that returns true if the channel is 40MHz, the peer is 40MHz /and/ the currently selected width is 40MHz, so if someone requests a channel width change, it'll correctly start transmitting at 20MHz even though it's associated at 40MHz. (which is perfectly legal.)
Ugh now I remember this mess in more detail. :-) Stay tuned.
Ok, this should be fine as-is just to use the new helpers.
I'd like to let that settle a bit whilst I go and update the rtwn selection logic a bit more in rtwn after these land. In particular I'll go and check the node channel width before transmitting on 20/40 MHz like I do with ath(4), and then we'll need to go over the rules for choosing a VHT rate / width when it's time to get VHT transmit rate handling into net80211.
done; and i cleaned up the 20/40MHz selection in a later diff in the stack.
(Although i think for RTL8192CU series chips HT40 is just going to be very broken until I fix firmware rate control, but that's a different story..)