MFC r344990:
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.

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

iwn: add watchdog for scanning.

Restart device if scanning was not done in time.

Tested by: david@catwhisker.org

PR: 209198
Differential Revision: https://reviews.freebsd.org/D6176

iwn: fix device reset after watchdog timeout.

Simple device reset (stop/start) is not enough here;
post-init state changes must be applied too.

Remove the software queue, which is a remnant of ifnet ifqueue.

Reviewed by: adrian
Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Migrate the stats API for iwn(4) into a cdev ioctl, rather than tying
into the vap.

This allows for possible hardware interaction without needing a vap
configured.

Replay r286410. Change KPI of how device drivers that provide wireless
connectivity interact with the net80211 stack.

Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.

Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:

- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
driver about any changes: number of wlan(4) interfaces, number of them
in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
driver experiences errors and can not attribute them to any specific
interface, driver updates ic_oerrors or ic_ierrors counters.

Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
now provided by net.wlan.devices sysctl.

Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann,
Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in
testing.

Reviewed by: adrian
Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Revert the wifi ifnet changes until things are more baked and tested.

* 286410
* 286413
* 286416

The initial commit broke a variety of debug and features that aren't
in the GENERIC kernels but are enabled in other platforms.

Change KPI of how device drivers that provide wireless connectivity interact
with the net80211 stack.

Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.

Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:

- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
driver about any changes: number of wlan(4) interfaces, number of them
in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
driver experiences errors and can not attribute them to any specific
interface, driver updates ic_oerrors or ic_ierrors counters.

Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
now provided by net.wlan.devices sysctl.

Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@,
op@ and lev@, who also participated in testing. Details here:

https://wiki.freebsd.org/projects/ifnet/net80211

Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not
tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances
of problems are low. The wtap wasn't compilable even before this change.
But the ndis driver is complex, and it is likely to be broken with this
commit. Help with testing and debugging it is appreciated.

Differential Revision: D2655, D2740
Sponsored by: Nginx, Inc.
Sponsored by: Netflix

First cut at attempting to buffer frames until we see a beacon.

The iwn(4) firmware forgets most of its channel state after an RXON
command. This means that any beacons its seen on passive 5GHz channels
are forgotten upon an association/authorisation request.
This unfortuantely means that 5GHz association almost always fails -
the assoc and/or auth frames are dropped with a status of "passive
channel, haven't seen a beacon yet." (0x90.)

So:

* add an xmit queue, global, to buffer frames
* modify the xmit path to use the mbuf tag from net80211
to specify raw frame details
* buffer xmit frames from both raw and non-raw paths
* if a beacon is seen in the RX path, schedule a taskqueue to
send said frames and un-buffer things.
* flush frames during state change back to INIT, or NIC
down/up/detach.

This isn't the final shape I'd like this to be in but it certainly
is better than 5GHz "not working at all".

Tested:

* Intel 5100, STA mode (before spilling coffee)
* Intel 5300, STA mode (after spilling coffee)

Story:

* This has been bugging me at work for months, which I just
worked around by throwing an ath(4) into my Lenovo T400 cardbus
slot.

* Our ops director discovered indeed FreeBSD runs well on the
Lenovo T420p, except for that pesky 5GHz thing. So now developers
also can have a T420p running FreeBSD to do work with.
Their #1 feedback to me - "boy it'd be nice if 5GHz wifi worked."

* .. then, I was at NANOG but stuck with 5GHz only wifi and no ath(4)
NIC to put in a laptop - and I snapped.

Thus, the reason this is actually work related.

MFC after: 2 weeks
Sponsored by: Norse Corp, Inc.

Fix antenna configuration, microcode version checks and rate selection
in preparation for the 5300 3x3 NIC.

During this particular adventure, I did indeed discover that a whole
swath of things made little to no sense.

Those included, and are fixed here:

* A lot of the antenna configuration bits assume the NIC has two receive
chains. That's blatantly untrue for NICs that don't.
* There was some disconnect between the antenna configuration when
forming a PLCP rate DWORD (which includes the transmit antenna
configuration), separate to the link quality antenna configuration.

So now there's helper functions to return which antenna configurations
to use and those are used wherever an antenna config is required.

* The 5300 does up to three stream TX/RX (so MCS0->23), however
the link quality table has only 16 slots. This means all of the
rate entries are .. well, dual-stream rates. If this is the case,
the "last MIMO" parameter can't be 16 or it panics the firmware.
Set it to 15.

* .. and since yes it has 16 slots, it only would try retransmitting
from MCS8->MCS23, which can be quite .. terrible. Hard-code the last
two retry slots to be the lowest configured rate.

* I noticed some transmit configuration command stuff is different
based on firmware API version, so I lifted that code from Linux.

* Add / augment some more logging to make it easier to capture this
stuff.

Now, 3x3 is still terrible because the link quality configuration is
plainly not good enough. I'll have to think about that.
However, the original goal of this - 3x3 operation on the Intel
5300 NIC - actually worked.

There are also rate control bugs in the way this driver handles
notifying the net80211 rate control code when AMPDU is enabled.
It always steps the rate up to the maximum rate possible - and
this eventually ends in much sadness. I'll fix that later.

As a side note - 2GHz HT40 now works on all the NICs I have tested.

As a second side note - this exposed some bad 3x3 behaviour in
the ath(4) rate control code where it starts off at a 3-stream rate
and doesn't downgrade quickly enough. This makes the initial
dhcp exchange take a long time. I'll fix the ath(4) rate code
to start at a low fixed 1x1 MCS rate and step up if everything
works out.

Tested:

* Intel 2200
* Intel 2230
* Intel 5300
* Intel 5100
* Intel 6205
* Intel 100

TODO:

* Test the other NICs more thoroughly!

Thank you to Michael Kosarev <russiane39@gmail.com> for donating the
Intel 5300 NIC and pestering me about it since last year to try and
make it all work.

Make iwn(4) able to get itself back into working condition after
"fatal firmware error" happens. Previously it was neccessary to reset
it manually, using "/etc/rc.d/netif restart".

Approved by: adrian@
MFC after: 1 month
Sponsored by: The FreeBSD Foundation

Track and expose the latest statistics from the firmware.

Tested:

* Intel Centrino 6205

- There's no need to keep track of resource IDs.
- Simplify MSI allocation and release. For a single one, we don't need to
fiddle with the MSI count and pci_release_msi(9) is smart enough to just
do nothing in case of INTx.
- Don't allocate MSI as RF_SHAREABLE.
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.

MFC after: 1 week

Begin fleshing out some code to handle tracking PLCP error rates
in preparation for the scan based retune logic.

The linux iwlwifi driver does a rescan (onto a non-active channel)
to force an RF retune when the PLCP error rates exceed a certain threshold.

* Add code to track HT PLCP rate errors;
* Separate out the PLCP error count fetch and update so the delta
can be used when checking for PLCP error rates;
* Implement the PLCP error logic from iwlwifi;
* For now, just print out whenever the error rate exceeds the
threshold.

The actual scan based retune will take a bit more effort; the scan
command code right now assumes that a scan state is passed in.
This does need to change to be more flexible (both for this and
in preparation for scanning multiple channels at once.)

Tested:

* 5100 (STA mode)
* 2200 (STA mode)
* 2230 (STA mode)

Overhaul the iwn(4) scan infrastructure to be slightly more "correct"
for these chipsets.

* Correctly set the active/passive flag in the scan request - this is
NOT a "is the channel active|passive"; it's to do with whether we
have an SSID to actively scan for or not. The firmware takes care
of the active/passive setup of the channel.

* Calculate the active/passive dwell time based on the beacon interval
and the channel mode, rather than using a hard coded value.

* For now, hardcode the scan service_time. It's defined as:

31:22 - number of beacon intervals to come back onto the home channel
for;
0:21 - time (microseconds) to come back onto the home channel for.

When doing an active scan when the NIC is active (whether we're associated
or not - it only matters if we've setup the NIC to a destination or not)
this determines how much time to stay on the home channel for when
scanning. We can tune this based on the amount of active traffic.

For now it's 4 beacon intervals and 100 microseconds.

* Fix the "good crc threshold" setting. It differs based on the NIC
firmware. Some older firmware required a workaround; the later
firmware instead treats the field as a flag.

* Enforce that we are not sending a scan command if one is already
pending. Any time this is done is a bug and it absolutely needs
to be fixed - so be very loud.

* Add the SCAN flag to a few debug messages that are scan related but
only occuring under STATE.

Now, this does get noisy when you're scanning in an actively busy 2GHz
network as the firmware (for reason I don't quite yet understand) seems
hell bent on staying on some passive channels longer than it should.
However, it should eventually recover and complete the scan.

This is a work in progress; please let me know if things get stuck or
if things improve!

Tested:

* intel centrino 2200
* intel centrino 2230
* intel 6200
* intel 5100
* intel 4965 (gets upset, but that's a known issue)

Obtained from: linux iwlwifi

Commit over some work to prepare the iwn(4) driver for further chipset
support.

* Extend the hardware base_params structure to include a bunch of hardware
flags indicating what is and isn't supported.

* Convert a bunch of the initial hardware configuration conditionals to
consult the base_params structure.

* Add new calibration code for temperature calibration for the Centrino 2xxx
series NICs.

* Add new bluetooth coexistence code for Centrino 2xxx series NICs.

* For NICs that support PAN (personal area networking), use a different
transmit queue and command queue setup, in preparation for said
PAN support.

* Extend the calibration array in iwn_softc to include enough space for
the new calibration types.

Tested (by myself, if not mentioned):

* Intel 4965
* Intel 5100
* Intel 6150
* Intel 2230
* Intel 2200 (eadler)
* Intel 1030
* Intel 6200
* Intel 6230
* Intel 6250
* Intel 6150
* Intel 100

What doesn't work:

* Intel 6235 - fails in calibration at startup

TODO:

* Testing on Intel 53xx series hardware

Submitted by: Cedric Gross <cg@cgross.info>

Begin fleshing out a knob to enable/disable bluetooth coexistence.

Some firmware versions seem to get very unhappy if they're sent btcoex
commands when they don't actually have bluetooth hardware in them.
So, disable sending them those commands.

Tested:

* 5100 (which has bluetooth, no problems)
* 4965 (which doesn't have bluetooth, but didn't seem to crash)
* 6200 (no bluetooth, seems to get unhappy being sent bluetooth commands.)

Prepare for the PAN (personal area network) support for iwn(4).

* Break out the single, static RX context into a pointer, and ..
* .. extend it to two RX contexts - a default and a PAN context.

Whilst here, add a few extra fields in preparation for further iwn(4)
work.

Tested:

* Intel 4965, STA mode - same level of stability
* Intel 5100, STA mode - no change

Submitted by: Cedric Gross <cg@gross.info>

Implement basic 802.11n awareness in the PHY and AMRR rate control code.

* Add 802.11n 2ghz and 5ghz tables, including legacy rates and up to
MCS23 rates (3x3.)

* Populate the rate code -> rate index lookup table with MCS _and_
normal rates, but _not_ the basic rate flag. Since the basic rate flag
is the same as the MCS flag, we can only use one.

* Introduce some accessor inlines that do PLCP and rate table lookup/access
and enforce that it doesn't set the basic rate bit. They're not
designed for MCS rates, so it will panic.

* Start converting drivers that use the rate table stuff to use the
accessor inlines and strip the basic flag.

* Teach AMRR about basic 11n - it's still as crap for MCS as it is
being used by iwn, so it's not a step _backwardS_.

* Convert iwn over to accept 11n MCS rates rather than 'translate' legacy
to MCS rates. It doesn't use a lookup table any longer; instead it's a
function which takes the current node (for HT parameters) and the
rate code, and returns the hardware PLCP code to use.

Tested:

* ath - it's a no-op, and it works that way
* iwn - both 11n and non-11n

Add support for TX packet aggregation.

Add support for RX packet aggregation.

Prepare for transmitting frames at MCS rates:
- instead of calling iwn_plcp_signal() for every frame, map the expected
value directly within wn->ridx
- concat plcp, rflags and xrflags, there is no clean byte boundary within
the flags, for example the antenna setting uses bit 6, 7 and 8
- there is still need for a custom rate to plcp mapping, as those expected
by the hardware are not conform to the std

Use the enhanced TX power information availabe on newer EEPROMs.

Add basic support for advanced bluetooth coexistence required
for 6005 gen2b (1030/6030) adapters.

Pull some features out of the firmware:
- If a ENH_SENS TLV section exit the firmware is capable of doing
enhanced sensitivity calibration.
- Newer devices/firmwares have more calibration commands therefore
hardcoding the noise gain/reset commands no longer works. It is
supposed to use the next index after the newest calibration type
support. Read the command index of the TLV section if available.

Add some new features:
- 6000 series devices need enhanced sensitivity calibration.
- 6000 series devices need a different setting for the shadow reg.
- set the IWN_FLAG_HAS_11N bit if the EEPROM says the device has 11n
support.

Obtained from: OpenBSD

Bring over the HAL/OPS changes, instead of two const structs it is now
slightly more dynamic.

Obtained from: OpenBSD

Just a whitespace sync, some more style(9) conform then others.

Sync comments with OpenBSD.

Shuffle code around a bit. Mostly to group functional connected things,
others to get the same order as the OpenBSD code.

Revert some of local calibration changes in favour of the OpenBSD
implementation. This includes the fix required for the 6050 series
devices.

Split up watchdog and calibration callout. This allows us to use different
timing on both and to remove some monitor mode specific hacks (which has
no calibration).

Remove IWN_FLAG_HAS_5GHZ and IWN_PCI_BAR0, both unused.

For 6000 series and newer devices the DC calibration results are no
longer requested of the boot firmware. Instead of sending those results
to the runtime firmware the firmware is told to do the DC calibration
itself.

MFC after: 1 week

Rewrite parts of the calibration code which is run while bringing up
the device:
- unobscure some of the code by moving it into its own functions
- get rid of some magic numbers
- create similar structure as the reference driver has, this should
make further syncs easier

Add support for firmware images in "type-length-value" format.

Obtained from: OpenBSD
MFC after: 2 weeks

Fix some small whitespace nits.

MFC after: 3 days

* Rename bluetooth coexistence flags, no binary change.
* Enable DC calibration and crystal calibration on Centrino Advanced-N
6250 parts.
* Workaround for a HW bug (does not affect 4965AGN) that may sporadically
affect latency under some rare circumstances. From a similar commit to
iwlwifi.
* Update sensitivity settings for 5000 series to workaround a performance
bug in the DSP (1000 is not affected so we keep the old values for 5000).
* Update sensitivity settings for 6000 series.
* Set differential gains on 6250 too (but use a 1.0 factor, not 1.5).
* Init OFDM sensitivity with min value (which depends on the chip)
instead of hardcoding it to 90.
* Read calibration version from ROM and set IWN_GP_DRIVER_CALIB_VER6
bit on 6x50 if version >= 6.

Approved by: rpaulo (mentor)
Obtained from: OpenBSD
MFC after: 2 weeks

net80211 rate control framework (net80211 ratectl).

This framework allows drivers to abstract the rate control algorithm and
just feed the framework with the usable parameters. The rate control
framework will now deal with passing the parameters to the selected
algorithm. Right now we have AMRR (the default) and RSSADAPT but there's
no way to select one with ifconfig, yet.
The objective is to have more rate control algorithms in the net80211
stack so all drivers[0] can use it. Ideally, we'll have the well-known
sample rate control algorithm in the net80211 at some point so all
drivers can use it (not just ath).

[0] all drivers that do rate control in software, that is.

Reviewed by: bschmidt, thompsa, weyongo
MFC after: 1 months

Revert iwn channel-argument handling of set_txpower() to r201822

Pass the channel argument as a real argument and not through
RXON. The RXON version seems to have problem with both the older
228.57.2.23 firmware and the latest 228.61.2.24 version resulting
in device initialization errors like:

wpa_supplicant[2928]: Failed to initiate AP scan.
kernel: firmware error log:
kernel: error type = "SYSASSERT" (0x00000005)
kernel: program counter = 0x0000147C
kernel: source line = 0x0000058B
kernel: error data = 0x0000058B00000000
kernel: branch link = 0x0000145A00001492
kernel: interrupt link = 0x000006DE00000000
kernel: time = 7310
...
kernel: iwn0: iwn_config: could not set TX power
kernel: iwn0: iwn_init_locked: could not configure device, error 35

By passing the current channel to hal->set_txpower() the firmware
error is fixed, at least for the 4965 chipset of my Thinkpad and
the ones tested by Bernhard.

Submitted by: Bernhard Schmidt <bschmidt@techwires.net>
Approved by: rpaulo

iwn(4) update. Notable changes:
* new firmware
* untested support for 1000 and 6000 series
* bgscan support
* remove unnecessary RXON changes
* allow setting of country/regdomain by enforcing channel flags read
from the EEPROM
* suspend/resume fixes
* RF kill switch fixes
* LED adjustments
* several bus_dma*() related fixes
* addressed some LORs
* many other bug fixes

Submitted by: Bernhard Schmidt <bschmidt at techwires.net>
Obtained from: Brandon Gooch <jamesbrandongooch at gmail dot com> (LED
related changes), Benjamin Kaduk <kaduk at mit dot edu>
(LOR fixes), OpenBSD

Updated iwn(4) driver supporting the newer series, 5000, 5150 and 5300.

Submitted by: Bernhard Schmidt <bschmidt at techwires.net>

Overhaul monitor mode handling:
o replace DLT_IEEE802_11 support in net80211 with DLT_IEEE802_11_RADIO
and remove explicit bpf support from wireless drivers; drivers now
use ieee80211_radiotap_attach to setup shared data structures that
hold the radiotap header for each packet tx/rx
o remove rx timestamp from the rx path; it was used only by the tdma support
for debugging and was mostly useless due to it being 32-bits and mostly
unavailable
o track DLT_IEEE80211_RADIO bpf attachments and maintain per-vap and
per-com state when there are active taps
o track the number of monitor mode vaps
o use bpf tap and monitor mode vap state to decide when to collect radiotap
state and dispatch frames; drivers no longer explicitly directly check
bpf state or use bpf calls to tap frames
o handle radiotap state updates on channel change in net80211; drivers
should not do this (unless they bypass net80211 which is almost always
a mistake)
o update various drivers to be more consistent/correct in handling radiotap
o update ral to include TSF in radiotap'd frames
o add promisc mode callback to wi

Reviewed by: cbzimmer, rpaulo, thompsa

Create a taskqueue for each wireless interface which provides a serialised
sleepable context for net80211 driver callbacks. This removes the need for USB
and firmware based drivers to roll their own code to defer the chip programming
for state changes, scan requests, channel changes and mcast/promisc updates.
When a driver callback completes the hardware state is now guaranteed to have
been updated and is in sync with net80211 layer.

This nukes around 1300 lines of code from the wireless device drivers making
them more readable and less race prone.

The net80211 layer has been updated as follows
- all state/channel changes are serialised on the taskqueue.
- ieee80211_new_state() always queues and can now be called from any context
- scanning runs from a single taskq function and executes to completion. driver
callbacks are synchronous so the channel, phy mode and rx filters are
guaranteed to be set in hardware before probe request frames are
transmitted.

Help and contributions from Sam Leffler.

Reviewed by: sam

Intel 4965 wireless driver (derived from openbsd driver of the same name)