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

[ath_hal] initialise ah_beaconInterval when the AP/IBSS/TDMA beacon is setup.

[ath_hal] rename the MCI state info routine.

It's not /really/ "get state".

Add initial ar9300 HAL support for the spectral scan mode.

ath(4): begin fleshing out a "reset type" extension to force cold/warn resets.

Right now the only way to force a cold reset is:

* The HAL itself detects it's needed, or
* The sysctl, setting all resets to be cold.

Trouble is, cold resets take quite a bit longer than warm resets.

However, there are situations where a cold reset would be nice.
Specifically, after a stuck beacon, BB/MAC hang, stuck calibration results,
etc.

The vendor HAL has a separate method to set the reset reason (which is
how HAL_RESET_BBPANIC gets set) which informs the HAL during the reset path
why it occured. This is almost but not quite the same; I may eventually
unify both approaches in the future.

This commit just extends HAL_RESET_TYPE to include both status (eg BBPANIC)
and type (eg do COLD.) None of the HAL code uses it yet though; that'll
come later.

It also is a big no-op in each HAL - I need to go teach each of the HALs
about cold/warm reset through this path.

Add a missing method - ath_hal_settsf64().

This is required for TDMA slave mode.

Add initial support for the HAL channel survey support to the AR9300 HAL.

This is used by the 'athsurvey' command to print out channel survey
statistics - % busy times transmit, receive and airtime.

It's as buggy and incomplete as the rest of the HAL survey support -
notably, tying into the ANI code to read channel stats and occasionally
getting garbage counters isn't very nice. It also doesn't (yet!) get
channel survey information during a scan. But it's good enough for
basic air-time debugging, which is why I'm committing it in this state.

Tested:

* AR9380, STA mode

Quieten some of the log spam from AR9300 sysctl tree walk and chip setup/reset
path.

* For now there's no exposed control over classic / LNA antenna diversity,
so just stub them out. Adding this will take quite a bit of time.

* Add a function to fetch the CTS timeout.

PR: kern/198558

Add ath_hal_setbeacontimers() to the AR9300 HAL.

This is a custom FreeBSD HAL method that is used by the TDMA code
to program the beacon timers directly without any guesswork/assumptions
by the HAL.

This brings up basic TDMA master/slave support on the AR9380 HAL,
however there are other issues preventing it from being stable.
(I'm seeing beacon interval instability, which may be due to
busy 2GHz air, but also may be due to some HAL configuration
issues with regards to ANI, or hardware timer programming, etc.)

Tested:

* AR9331 (Carambola2), STA, AP, adhoc and TDMA master mode.

Update the AR9300 HAL to the latest public available HAL from QCA.

I've been sitting on this for a year or so now; I've finally
tested it on enough devices to be reasonably sure it won't
cause too much drama. But, if you see issues, please email me.

Tested (all STA mode):

PCIe:

* AR9380
* AR9390
* AR9580
* AR9462
* AR9485

SoC:

* QCA9550
* AR9331
* AR9342

Oops - use the correct argument order for ar9300_set_beacon().

(It's only an issue in AP/adhoc modes. But, still. Grr.)

Override the bt enable/disable methods for AR9462 (jupiter) and
AR9565 (Aphrodite.) These need to use the MCI routines, not
the legacy 2-wire / 3-wire bluetooth coexistence methods.

Tested:

* AR9462 (WB222); STA mode

Tie in the MCI bluetooth coexistence functions into the HAL.

Tested:

* AR9462 (WB222)

Remove this stuff - it's no longer needed here.

Add initial support for the AR9485 CUS198 / CUS230 variants.

These variants have a few differences from the default AR9485 NIC,
namely:

* a non-default antenna switch config;
* slightly different RX gain table setup;
* an external XLNA hooked up to a GPIO pin;
* (and not yet done) RSSI threshold differences when
doing slow diversity.

To make this possible:

* Add the PCI device list from Linux ath9k, complete with vendor and
sub-vendor IDs for various things to be enabled;
* .. and until FreeBSD learns about a PCI device list like this,
write a search function inspired by the USB device enumeration code;
* add HAL_OPS_CONFIG to the HAL attach methods; the HAL can use this
to initialise its local driver parameters upon attach;
* copy these parameters over in the AR9300 HAL;
* don't default to override the antenna switch - only do it for
the chips that require it;
* I brought over ar9300_attenuation_apply() from ath9k which is cleaner
and easier to read for this particular NIC.

This is a work in progress. I'm worried that there's some post-AR9380
NIC out there which doesn't work without the antenna override set as
I currently haven't implemented bluetooth coexistence for the AR9380
and later HAL. But I'd rather have this code in the tree and fix it
up before 11.0-RELEASE happens versus having a set of newer NICs
in laptops be effectively RX deaf.

Tested:

* AR9380 (STA)
* AR9485 CUS198 (STA)

Obtained from: Qualcomm Atheros, Linux ath9k

Quieten the AR9300 HAL attach a little - the setupXTxDesc method
is only called during attach now.

The EDMA TX path never calls this - only the legacy TX path does.

Don't double-call the ar9300 stub function method.

Add ar9300_get_next_tbtt().

Tested:

* AR9380, STA mode

Add a stub AR93xx RF module just to keep the linker happy.

When building AR933x test images, I'd like to only build only the ar9300
HAL. To do this, it needs to supply an RF linker entry or it won't compile.

Tested:

* AR933x test builds

The AR9300 HAL uses this config to program AR_PHY_SWITCH_COM_2 on AR9485
NICs which have bluetooth coexistence enabled.

The WB225 NIC has the common antenna switch configuration set to 0x0 which
disables all external switch bit setting. This obviously won't work when
doing coexistence.

This value is a magic value from the windows .inf files. It _looks_ right
but I haven't yet verified it - unfortunately my AR9285+AR3012 BT combo
has an earlier BT device which doesn't actually _have_ firmware on it.
So I have to fix ath3kfw to handle loading in firmware into the newer
NICs before I can finish testing this.

This may not hold true for CUS198, which is another custom AR9485 board.

Add bluetooth setup method functions to the HAL.

Tie in the LNA diversity configuration functions into the HAL.

Bring over my FreeBSD modifications for the AR9300 HAL to make it
work in FreeBSD.

This is still heavily a work in progress but I'd rather it start
shipping in -HEAD sooner rather than later.

This doesn't (yet) link it into the build system either for a static
kernel or as a module; that will come later (after many, many make universe
tests.)