The initial thought of migrating the LinuxKPI 802.11 enum into net80211
for shared use did not work out well.  Currently in the need for yet
another adjustment, I decided to undo/de-couple net80211 and
LinuxKPI 802.11 again.

The enum name now gets used in LinuxKPI based wifi drivers and it
turns out it is spelt differntly than what I used initially.
This creates a conflict.

net80211 still in the need to be able to express BW_320 in an uint8_t
will likely be fine with the current solution as well.  Rename the
enum and prefixes in net80211 to "net80211" instead of "ieee80211".
Apart from the names/prefix we leave the values the same.

In LinuxKPI add the enum with the expected name and use it there
throughout to make modern versions of LinuxKPI based wifi drivers
compile.

Sponsored by:	The FreeBSD Foundation
Fixes:		ca389486a9599, 2c8b0d6205f6f
MFC after:	3 days
Reviewed by:	adrian
Differential Revision: https://reviews.freebsd.org/D52064

ieee80211_node_set_txrate_ht_mcsrate() takes an MCS rate from 0..76,
the high bit (IEEE80211_RATE_MCS) must not be set.

This is definitely my fault - I likely didn't get to testing this
diff when I changed it from ieee80211_node_set_txrate_dot11rate()
just before landing.

Differential Revision:	https://reviews.freebsd.org/D49197
Reviewed by:	bz

This just mechanically converts things.

* For linuxkpi, it was just used for display.
* For uath, it was just used for display, as firmware
  doesn't report it up.

Differential Revision:	https://reviews.freebsd.org/D48602
Reviewed by:	bz, thj

This should be a *9 rather than a *10 so higher stream MCS rates
(eg comparing MCS0 and MCS8) that have slightly longer average transmit
times (but better burst transmit times) get considered.

This mirrors what the later code does when considering if a rate
change is needed.

Locally tested:

* AR9280, AP mode
* AR9380, AP mode

Differential Revision:	https://reviews.freebsd.org/D47988
Reviewed by:	imp

net80211 node ni_chw currently encodes the channel width as Mhz number.
LinuxKPI 802.11 uses enum ieee80211_sta_rx_bw for the same.

Rather than keeping the "20" and "40" throughout the code (eventually
expanded to 80/160/320) switch them over to use the enum throughout
and add a print mask for debug output.  While designed as bitmask it
is not supposed to be used as such;  the bitmask is only used to be
able to use %b with a print mask.

Once we get to 320Mhz channel widths we would otherwise also need to
extend the uint8_t in struct ieee80211_node; making
enum ieee80211_sta_rx_bw __packed allows us for three more channel
widths without breaking the KBI (if we were not to use %b with a
print_mask but use a lookup function for the string we could extend
it for a long time).

Sponsored by:	The FreeBSD Foundation
MFC after:	14 days
Reviewed by:	adrian
Differential Revision: https://reviews.freebsd.org/D47891

MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D43096

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with:		pfg
MFC After:		3 days
Sponsored by:		Netflix