net80211: fix VHT80/VHT160 transmit width checks

[adrian]

Summary

I didn't double check to see if ni_chw had been updated to actually
implement values other than 20/40. It's just implementing the
HT channel width stuff during both association and upon receiving
a HT TX channel width action frame.

This meant the VHT80/VHT160 transmit width checks were never
going to be true, as ni_chw is never set to VHT80 / VHT160.

After checking the HT action frame and looking for VHT changes,
I'm pretty sure there's nothing explicit about VHT width, as it's
normally done via CCA (clear channel access) and/or RTS/CTS exchanges -
each 20MHz subchannel is RTS/CTS'ed / will be checked and if they're
busy, a narrower frame will be transmitted.

So, change the VHT80 / VHT160 checks to only check if ni_chw is 20MHz.
If it's 20MHz then a HT action frame has come out saying to TX at 20MHz,
and we should obey it. Otherwise, do 80/160MHz as available.

[bz]

Too many (cached) values in net80211 representing something rather than a simple accessor function doing the thing right in one place.
I'll back out the IEEE80211_STA_RX_BW_* change as you are back to 20/40 only now to not be confusing once this is landed.

[adrian]

In D50096#1143047, @bz wrote:

Too many (cached) values in net80211 representing something rather than a simple accessor function doing the thing right in one place.
I'll back out the IEEE80211_STA_RX_BW_* change as you are back to 20/40 only now to not be confusing once this is landed.

Let's hold off on that; I can add "create an accessor function" first and go update all the consumers of this thing. Then we can nuke it?

[bz]

In D50096#1143052, @adrian wrote:

In D50096#1143047, @bz wrote:

Too many (cached) values in net80211 representing something rather than a simple accessor function doing the thing right in one place.
I'll back out the IEEE80211_STA_RX_BW_* change as you are back to 20/40 only now to not be confusing once this is landed.

Let's hold off on that; I can add "create an accessor function" first and go update all the consumers of this thing. Then we can nuke it?

No, because if it ships in 14.3-R it's baked into that branch. The accessor function won't make a difference here if you keep treating ni_chw pure HT.