Revert "Enter the network epoch in USB WiFi drivers when processing input"

This reverts commit 17c328b6aebfa03cd1c2cbfbbc617e3b341bf1e4.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

otus: splnet isn't a thing, remove place holders

Even though it's if 0'd code, remove splnet/splx. This code can't
possibly run on FreeBSD, but having it here as a marker isn't especially
helpful. It causes a false positive on grepping otherwise.

Sponsored by: Netflix

sys: Remove $FreeBSD$: one-line .c pattern

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

DrvAPI: Trivial mechanical conversions for various drivers

Mechanically convert the following drivers, with trivial changes:
* ipw(4)
* igc(4)
* enetc(4)
* malo(4)
* nfe(4)
* bxe(4)
* awg(4)
* otus(4)
* rtwn(4)
* bnxt(4)
* ath(4)

Sponsored by: Juniper Networks, Inc.

otus: Remove unused devclass argument to DRIVER_MODULE.

otus: Return computed error value instead of ENXIO from otus_raw_xmit.

WiFi: fix ieee80211_media_change() callers

In r178354 with the introduction of multi-bss ("vap") support factoring
out started and with r193340 ieee80211_media_change() no longer returned
ENETRESET but only 0 or error.
As ieee80211(9) tells the ieee80211_media_change() function should not
be called directly but is registered with ieee80211_vap_attach() instead.

Some drivers have not been fully converted. After fixing the return
checking some of these functions were simply wrappers between
ieee80211_vap_attach() and ieee80211_media_change(), so remove the extra
function, where possible as well.

PR: 248955
Submitted by: Tong Zhang (ztong0001 gmail.com) (original)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation

otus: clean up empty lines in .c and .h files

[otus] enable 802.11n for 2GHz and 5GHz.

This flips on basic 11n for 2GHz/5GHz station operation.

* It flips on HT20 and MCS rates;
* It enables A-MPDU decap - the payload format is a bit different;
* It does do some basic checks for HT40 but I haven't yet flipped on
HT40 support;
* It enables software A-MSDU transmit; I honestly don't want to make
A-MPDU TX work and there are apparently issues with QoS and A-MPDU TX.
So I totally am ignoring A-MPDU TX;
* MCS rate transmit is fine.

I haven't:

* A-MPDU TX, as I said above;
* made radiotap work fully;
* HT40;
* short-GI support;
* lots of other stuff that honestly no-one is likely to use.

But! Hey, this is another ye olde 11n USB NIC that now works pretty OK
in 11n rates. A-MPDU receive seems fine enough given it's a draft-n
device from before 2010.

Tested:

* Ye olde UB82 Test NIC (AR9170 + AR9104) - 2GHz/5GHz

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (7 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked).
Use it in preparation for a general review of all nodes.

This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.

Mark all low hanging fruits as MPSAFE.

Reviewed by: markj
Approved by: kib (mentor, blanket)
Differential Revision: https://reviews.freebsd.org/D23626

Enter the network epoch in USB WiFi drivers when processing input
mbuf queues.

Submitted by: Idwer Vollering <vidwer gmail.com>

Convert to if_foreach_llmaddr() KPI.

urtw(4), otus(4), iwi(4): allow to set non-default MAC address via ifconfig(8)

Tested with Netgear WG111 v3 (RTL8187B, urtw(4)), STA mode.

MFC after: 1 week

Fix ieee80211_radiotap(9) usage in wireless drivers:

- Alignment issues:
* Add missing __packed attributes + padding across all drivers; in
most places there was an assumption that padding will be always
minimally suitable; in few places - e.g., in urtw(4) / rtwn(4) -
padding was just missing.
* Add __aligned(8) attribute for all Rx radiotap headers since they can
contain 64-bit TSF timestamp; it cannot appear in Tx radiotap headers, so
just drop the attribute here. Refresh ieee80211_radiotap(9) man page
accordingly.

- Since net80211 automatically updates channel frequency / flags in
ieee80211_radiotap_chan_change() drop duplicate setup for these fields
in drivers.

Tested with Netgear WG111 v3 (urtw(4)), STA mode.

MFC after: 2 weeks

ifnet: Replace if_addr_lock rwlock with epoch + mutex

Run on LLNW canaries and tested by pho@

gallatin:
Using a 14-core, 28-HTT single socket E5-2697 v3 with a 40GbE MLX5
based ConnectX 4-LX NIC, I see an almost 12% improvement in received
packet rate, and a larger improvement in bytes delivered all the way
to userspace.

When the host receiving 64 streams of netperf -H $DUT -t UDP_STREAM -- -m 1,
I see, using nstat -I mce0 1 before the patch:

InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree
4.98 0.00 4.42 0.00 4235592 33 83.80 4720653 2149771 1235 247.32
4.73 0.00 4.20 0.00 4025260 33 82.99 4724900 2139833 1204 247.32
4.72 0.00 4.20 0.00 4035252 33 82.14 4719162 2132023 1264 247.32
4.71 0.00 4.21 0.00 4073206 33 83.68 4744973 2123317 1347 247.32
4.72 0.00 4.21 0.00 4061118 33 80.82 4713615 2188091 1490 247.32
4.72 0.00 4.21 0.00 4051675 33 85.29 4727399 2109011 1205 247.32
4.73 0.00 4.21 0.00 4039056 33 84.65 4724735 2102603 1053 247.32

After the patch

InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree
5.43 0.00 4.20 0.00 3313143 33 84.96 5434214 1900162 2656 245.51
5.43 0.00 4.20 0.00 3308527 33 85.24 5439695 1809382 2521 245.51
5.42 0.00 4.19 0.00 3316778 33 87.54 5416028 1805835 2256 245.51
5.42 0.00 4.19 0.00 3317673 33 90.44 5426044 1763056 2332 245.51
5.42 0.00 4.19 0.00 3314839 33 88.11 5435732 1792218 2499 245.52
5.44 0.00 4.19 0.00 3293228 33 91.84 5426301 1668597 2121 245.52

Similarly, netperf reports 230Mb/s before the patch, and 270Mb/s after the patch

Reviewed by: gallatin
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D15366

otus(4): check mcast / mgt / ucast rates during Tx descriptor setup

These parameters may be changed via ifconfig(8); by default,
mgt / mcast rates are lowest possible and ucast rate is not set
(matches previous configuration).

While here, store some variables locally for better readability.

[net80211] convert all of the WME use over to a temporary copy of WME info.

This removes the direct WME info access in the ieee80211com struct and instead
provides a method of fetching the data. Right now it's a no-op but eventually
it'll turn into a per-VAP method for drivers that support it (eg iwn, iwm,
upcoming ath10k work) as things like p2p support require this kind of behaviour.

Tested:

* ath(4), STA and AP mode

TODO:

* yes, this is slightly stack size-y, but it is an important first step
to get drivers migrated over to a sensible WME API. A lot of per-phy things
need to be converted to per-VAP before P2P, 11ac firmware, etc stuff shows up.

net80211 drivers: fix rate setup for EAPOL frames, obtain Tx parameters
directly from the node.

- Use ni_txparms directly instead of calculating them manually every time
- Move M_EAPOL flag check upper; otherwise it may be skipped due to
'ucastrate' / 'mcastrate' check
- Use 'mgtrate' for control frames too (see ifconfig(8), mgtrate parameter)
- Add few more M_EAPOL checks where it was missing (zyd(4), ural(4),
urtw(4))
- Few unrelated cleanups

Tested with:
- Intel 6205 (iwn(4)), STA mode;
- WUSB54GC (rum(4)), HOSTAP mode + RTL8188EU (rtwn(4)), STA mode.

Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D9811

net80211: convert all ieee80211_input_mimo*() consumers
to ieee80211_add_rx_params() + drop last (ieee80211_rx_stats) parameter

Note: there is an additional check for ieee80211_get_rx_params()
return value (which does not exist in the original diff).

Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D8207

[net80211] extend the ieee80211_rx_stats struct to include more information.

There are a variety of more interesting RX statistics that we should
keep track of but we don't. This is a starting point for adding more
information.

Specifically:

* now the RX rate information and some of the packet status is
passed up;
* The 32 bit or 64 bit TSF is passed up;
* the PHY mode is passed up;
* the "I'm decap'ed AMSDU!" state is passed up;
* number of RX chains is bumped to 4.

This is all mostly a placeholder for getting the data into the RX status
before we pass it up to net80211 - unfortunately we don't yet enforce
that drivers provide it, nor do we pass the provided info back up the
stack so anyone can use the data.

We're going to need to use some of this data moving forward.
Notably, now that some hardware can do AMSDU decap for us (the intel iwm
driver can do it when we flip it on; the ath10k port I'm doing does
it for us) then we need to pass it up through the stack so the duplicate
RX sequence numbers and crypto/IV details don't cause the packet to
be dropped and/or counted against a replay counter.

It's also the beginning of being able to do more interesting node
accounting in net80211. Specifically, once drivers start populating
per-packet rate information, AMPDU information, timestamps, etc,
we can start providing histograms of rate-versus-RSSI, account
for receive time spent per node and other such interesting things.

(Note: I'm also hoping to include ranging and RTT information for
future chipset support; and it's likely going to include it in
this kind of fashion.)

net80211: ieee80211_ratectl*: switch to reusable KPI

Replace various void * / int argument combinations with common structures:
- ieee80211_ratectl_tx_status for *_tx_complete();
- ieee80211_ratectl_tx_stats for *_tx_update();

While here, improve amrr_tx_update() for a bit:
1. In case, if receiver is not known (typical for Ralink USB drivers),
refresh Tx rate for all nodes on the interface.
2. There was a misuse:
- otus(4) sends non-decreasing counters (as originally intended);
- but ural(4), rum(4) and run(4) are using 'read & clear' registers
to obtain statistics for some period of time (and those 'last period'
values are used as arguments for tx_update()). If arguments are not big
enough, they are just discarded after the next call.

Fix: move counting into *_tx_update()
(now otus(4) will zero out all node counters after every tx_update() call)

Tested with:
- Intel 3945BG (wpi(4)), STA mode.
- WUSB54GC (rum(4)), STA / HOSTAP mode.
- RTL8188EU (urtwn(4)), STA mode.

Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D8037

otus: minor catchup with OpenBSD.

Bump the OpenBSD revision tag since the corresponding changes don't
apply to us and drop an unnecessary header.

No functional change.

[otus] implement monitor mode.

* break out the operating mode and rx filter into new functions, rather
than them being hard-coded
* if we're in sniffer mode or not associated, set the BSS MAC to all zero,
rather than relying on a chip reset to do it for us
* add comments about .. how interestingly buggy the chip is.

Tested:

* AR9170 + AR9102, STA+monitor mode

Obtained from: linux carl9170 (general chip workings, constant definitions)

otus: switch to ieee80211_add_channel_list_*()

- Use device's channel list instead of default one
(from ieee80211_init_channels()).
- Sort channels (ieee80211_add_channel_list_* requirement).
- Add ic_getradiocaps() method.

Added channels:
2GHz band: 12, 13 and 14.
5GHz band: 34, 38, 42, 46 and 165.

Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D6145

net80211 + drivers: hide size of 'bands' array behind a macro.

Auto-replace 'howmany(IEEE80211_MODE_MAX, 8)' with 'IEEE80211_MODE_BYTES'.
No functional changes.

net80211: replace internal LE_READ_*/LE_WRITE_* macro with system
le*dec / le*enc functions.

Replace net80211 specific macros with system-wide bytestream
encoding/decoding functions:
- LE_READ_2 -> le16dec
- LE_READ_4 -> le32dec
- LE_WRITE_2 -> le16enc
- LE_WRITE_4 -> le32enc

+ drop ieee80211_input.h include, where it was included for these
operations only.

Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D6030

These files were getting sys/malloc.h and vm/uma.h with header pollution
via sys/mbuf.h

net80211 drivers: fix ieee80211_init_channels() usage

Fix out-of-bounds read (all) / write (11n capable) for drivers
that are using ieee80211_init_channels() to initialize channel list.

Tested with:
* RTL8188EU, STA mode.
* RTL8188CUS, STA mode.
* WUSB54GC, HOSTAP mode.

Approved by: adrian (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D4818

net80211: remove hardcoded slot time durations from drivers

- Add IEEE80211_GET_SLOTTIME(ic) macro.
- Use predefined macroses to set slot time.

Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D4044

net80211: WME callback cleanup in various drivers

Since r288350, ic_wme_task() is called via ieee80211_runtask(),
so, any additional deferring from the driver side is not needed.

Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D4072

otus(4) - monitor mode fixes, large-mbuf crash fix

* refactor out the rx filter and operating mode code into a separate
method.
* add some comments about what's left with setting the operating mode
based on what carl9170 does.
* comment out some init from otus_init_mac() - it's no longer needed as
it's always init'ed now.
* add debugging and a missing return around a failure to call m_get2() -
during monitor mode operation I found RXing of frames > 2k, which
fails allocation. I'm sure they're valid (it's configuring 11n RX and
receiving 11n frames even though the driver doesn't "do" 11n)
and may be A-MSDU; but allocations fail and we should handle that
gracefully.

Tested:

* UB82 reference NIC (AR9170 + AR9104 2x2 dual band NIC); STA and
monitor mode operation.

otus(4) - add missing ieee80211_free_node() call.

otus(4) - demagicify register names.

Obtained from: Linux carl9170 hw.h

otus(4): begin supporting raw transmit parameters in otus_tx()

* Add a comment about the parameters I should support, stolen shamelessly
from iwn(4);
* Implement the rate bit for the raw transmit path;
* Print out the host-order versions of each of the transmit bits, so
I have a hope in heck of debugging why things are going wrong.

This still doesn't fix 5GHz in the office but that's likely due to a lot
of other configuration parameters being 2GHz-specific. That'll come next.

Tested:

* AR9170 + AR9103 (2/5GHz) 2x2, 5GHz association

otus(4) - use the local node alloc function so there's space for statistics.

* Use the correct malloc type for node allocation - M_80211_NODE - so
the default node free method in net80211 will work correctly.
* Fix otus_node_alloc() to suit FreeBSD's net80211.
* .. and actually call otus_node_alloc() so there's space for the
per-node tx statistics. Otherwise, well, it will be scribbling over
random memory.

Tested:

* AR9170, STA mode

otus(4) - add initial monitor mode; use lowest rate for EAPOL

The monitor mode stuff is from the openbsd driver, but it doesn't
100% work. It doesn't seem to get all frames for all BSSes.
However, it's enough to at start debugging things. That 0xffffffff
write is /I think/ the RX filter, but I am still not 100% sure about
it all.

Then, whilst here, use the lowest rate for EAPOL frames. This is just
generally a good thing to do.

net80211 drivers: eliminate any references to sc_rxtap_len/sc_txtap_len (never used here)

Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3776

net80211: move ieee80211_free_node() call on error from ic_raw_xmit() to ieee80211_raw_output().

This doesn't free the mbuf upon error; the driver ic_raw_xmit method is still
doing that.

Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3774

if_otus fixes; add fast-frames support.

Fast-frames:

* include opt_wlan.h ; tsk to not doing it earlier;
* add a tx pending tracking counter for seeing how deep
the hardware TX queue is;
* add the frame aging code from if_ath;
* add fast-frames capability to the driver setup.

Bugs:

* free the buffers (and node references) before
detaching net80211 state. This prevents a use-after-free in
the node free path where we've destroyed net80211 underneath it.

Track the command response code buffer size and verify it in the
receive path.

Fix a bug in the TX command handling - log when a too-large payload is
sent, and fix a bug I found when doing so.

Add an initial driver for the AR9170 series draft-11n hardware from
Atheros.

Thanks to OpenBSD for providing a driver based on the original
Atheros open source driver circa 2008. This uses the early, pre-carl9170
atheros provided firmware.

It only supports 11bg at the moment. I've not tested it with 11a
(and so the TX rate control logic may be slightly wrong!) so if
you do have the dual-band version of this hardware please do let me know.

Tested:

* AR9170, TP-Link WN821N 2GHz.

TODO:

* Hook this up to a non-module build.