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

Implement STBC receive frame statistics.

The AR9280 and later can receive STBC. This adds some statistics
tracking to count these frames.

A patch to athstats will be forthcoming.

Fix a subtle corner case surrounding the handling of OFDM restart along
with AMPDU aggregate delimiters.

If there's an OFDM restart during an aggregate, the hardware ACKs
the previous frame, but communicates the RXed frame to the hardware
as having had CRC delimiter error + OFDM_RESTART phy error.
The frame however didn't have a CRC error and since the hardware ACKed
the aggregate to the sender, it thinks the frame was received.

Since I have no idea how often this occurs in the real world, add a
debug statement so trigger whenever this occurs. I'd appreciate an
email if someone finds this particular situation is triggered.

On second thought, let's just set both CRC and PHY errors together on
frames that have it and let the upper layer sort it out.

PR: kern/169362

Sometimes the AR5416 sends back radar PHY errors with both the PHY error
and the CRC error bits set. The radar payload is correct.

When this happens, the stack doesn't see them PHY error frames and
isn't interpreted as a PHY error. So, no radar detection and no radiotap
PHY error handling.

Now, this may introduce some weird issues if the MAC sends up some other
combination of CRC error + PHY error frames; this commit would break that
and mark them as PHY errors instead of CRC errors.

I may tinker with this a little more to pass radar/early radar/spectral
frames up as PHY errors if the CRC bit is set, to restore the previous
behaviour (where if CRC is set on a PHY error frame, it's marked as a CRC
error rather than PHY error.)

Tested on: AR5416, over the air, to a USRP N200 which is generating a
large number of a variety of radar pulses.
TODO: Test on AR9130, AR9160, AR9280 (and maybe radar pulses on
2GHz on AR9285/AR9287.)

PR: kern/169362

Add an AR5416 PCU DMA stop method, as a check for the AR9130 is needed.

The reference driver has a 3ms delay for the AR9130 but I'm not as yet
sure why. From what I can gather, it's likely waiting for some FIFO
flush to occur.

At some point in the future it may be worthwhile adding a WMAC
FIFO flush here, but that'd require some side-call through to the SoC
DDR flush routines.

Obtained from: Atheros

Remove an unused variable.

For now (ie: until autosleep support is fully fleshed out), always clear
all of the RX status fields when initialising a new RX descriptor.

Bring over AR5416 specific RX filter get/set routines.

This in particular fixes radar PHY handling - on the AR5212
NIC, one enables the AR_PHY_ERR_RADAR bit in AR_PHY_ERR;
the AR5416 and later also needs a bit set in AR_RX_FILTER.

A follow-up commit is needed to convert the AR5416 ANI code
to use this particular method, as it's currently using the
AR5212 methods directly.

Obtained from: Atheros
Approved by: re (kib)

Add a HAL capability bit for supporting self-linked RX descriptors and disable it for the 11n chipsets.

From the ath9k source:

==

11N: we can no longer afford to self link the last descriptor.
MAC acknowledges BA status as long as it copies frames to host
buffer (or rx fifo). This can incorrectly acknowledge packets
to a sender if last desc is self-linked.

==

Since this is useful for pre-AR5416 chips that communicate PHY errors
via error frames rather than by on-chip counters, leave the support
in there, but disable it for AR5416 and later.

From ath9k - clear the RX descriptor status before recycling it.

Replace Id keyword with the FreeBSD keyword.

add FreeBSD property

import ath hal

Replace most compile-time support options with linker sets for
chip and RF backend support:
o add OS_DATA_SET and OS_SET_DECLARE os requirements for setting
up linker sets
o add AH_CHIP macro for registering chip support (e.g. 5210)
o add AH_RF macro for registering RF support (e.g. 2413); note
this isn't required for single chip solutions where there's no
ambiguity (e.g. 5416/9160+2133) but for 5212 class parts it's
required because of the multi-chip solutions
o remove all uses of AH_SUPPORT_AR5210, AH_SUPPORT_AR5211, AH_SUPPORT_5212,
and AH_SUPPORT_AR9160; still need AH_SUPPORT_AR5416 to enable the 11n
descriptor formats and 5312 support is presently broken
o remove all uses of AH_SUPPORT_2133, AH_SUPPORT_2413, AH_SUPPORT_5111,
AH_SUPPORT_5112, AH_SUPPORT_2417, AH_SUPPORT_2425, and AH_SUPPORT_5413;
5312-related support still requires fixup

Remaining issues:
o fixup SoC attach
o ath_hal_attach uses a hack to probe w/o access to the vendorid
o fallback handling of parts w/o a macrev needs to be restored

Update to later code from my repository:
o many bug fixes
o add new periodic calibration api
o break up 5416 periodic calibration code in preparation for 928x
o move get noise floor to rf backends
o 5416-specific ani (still disabled)
o modularize 5210 eeprom format a la other eeprom formats
o start cleaning up regdomain code
o prepare for proper 1/2 and 1/4 width channel support
o bring back 900MHz card support
o clean up 5212 rf version handling
o add 1/2 and 1/4 width channel support for 5212 parts
o split 5212 rfgain handling out
o improve ani debugging
o add AH_USE_INIPDGAIN compile option
o purge a bunch of dead 5212 state
o add 1/2 and 1/4 rate modes
o remove HAL_CAP_CHAN_HALFRATE and HAL_CAP_CHAN_QUARTERRATE; the
same info can now be deduced from the set of supported modes

virgin import of ath hal