- Copy stable/10 (r259064) to releng/10.0 as part of the
10.0-RELEASE cycle.
- Update __FreeBSD_version [1]
- Set branch name to -RC1

[1] 10.0-CURRENT __FreeBSD_version value ended at '55', so
start releng/10.0 at '100' so the branch is started with
a value ending in zero.

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

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

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

Migrate the LNA mixing diversity machinery from the AR9285 HAL to the driver.

The AR9485 chip and AR933x SoC both implement LNA diversity.
There are a few extra things that need to happen before this can be
flipped on for those chips (mostly to do with setting up the different
bias values and LNA1/LNA2 RSSI differences) but the first stage is
putting this code into the driver layer so it can be reused.

This has the added benefit of making it easier to expose configuration
options and diagnostic information via the ioctl API. That's not yet
being done but it sure would be nice to do so.

Tested:

* AR9285, with LNA diversity enabled
* AR9285, with LNA diversity disabled in EEPROM

Add bluetooth fixes to the AR5416/AR92xx HAL:

* Call the bluetooth setup function during the reset path, so the bluetooth
settings are actually initialised.
* Call the AR9285 diversity functions during bluetooth setup; so the AR9285
diversity and antenna configuration registers are correctly programmed
* Misc debugging info.

Tested:

* AR9285+AR3011 bluetooth combo; this code itself doesn't enable bluetooth
coexistence but it's part of what I'm currently using.

As a temporary work-around (read: until there's a nice API for exposing
and controlling this form of antenna diversity) - print out the AR9285
antenna diversity configuration at attach time.

This will help track down and diagose if/when people have connectivity
issues on cards (eg if they connect a single antenna to LNA1, yet the
card has RX configured to only occur on LNA2.)

Tested:

* AR9285 w/ antenna diversity enabled in EEPROM;
* AR9285 w/ antenna diversity disabled in EEPROM; mapping only to a
single antenna (LNA1.)

Add a new capability flag to announce that the chip implements LNA mixing
for the RX path.

This is different to the div comb HAL flag, that says it actually
can use this for RX diversity (the "slow" diversity path implemented
but disabled in the AR9285 HAL code.)

Tested:

* AR9285, STA operation

Bring over the basic spectral scan framework code from Qualcomm Atheros.

This includes the HAL routines to setup, enable/activate/disable spectral
scan and configure the relevant registers.

This still requires driver interaction to enable spectral scan reporting.
Specifically:

* call ah_spectralConfigure() to configure and enable spectral scan;
* .. there's currently no way to disable spectral scan... that will have
to follow.
* call ah_spectralStart() to force start a spectral report;
* call ah_spectralStop() to force stop an active spectral report.

The spectral scan results appear as PHY errors (type 0x5 on the AR9280,
same as radar) but with the spectral scan bit set (0x10 in the last byte
of the frame) identifying it as a spectral report rather than a radar
FFT report.

Caveats:

* It's likely quite difficult to run spectral _and_ radar at the same
time. Enabling spectral scan disables the radar thresholds but
leaves radar enabled. Thus, the driver (for now) needs to ensure
that only one or the other is enabled.

* .. it needs testing on HT40 mode.

Tested:

* AR9280 in STA mode, HT/20 only

TODO:

* Test on AR9285, AR9287;
* Test in both HT20 and HT40 modes;
* .. all the driver glue.

Obtained from: Qualcomm Atheros

Override the BT coex parameter function for the AR9285.

HAL updates!

* Add some more ANI spur immunity levels.
* For AR5111 radios attached to an AR5212, limit the 5GHz channels
that are available. A later revision of the AR5111 supports the 4.9GHz
PSB channels but right now there's no check in place for the radio
revision.

If someone wants PSB support on AR5212+AR5111 radios then please let
me know and I'll add the relevant version check.

Obtained from: Qualcomm Atheros

Set the HAL combined antenna diversity capability if the AR9285
EEPROM settings allow it.

Add an disabled workaround for the AR9285SE.

This just requires a little HAL change (add a new config parameter) and
some glue in if_ath_pci.c, however I'm leaving this up for someone else
to do.

Obtained from: Qualcomm Atheros

Bring over the AR9285 specific PCIe suspend/resume/ASPM workarounds.

Obtained from: Qualcomm Atheros, Linux ath9k

oops - ath_hal_disablepcie is actually destined for another purpose,
not to disable the PCIe PHY in prepration for reset.

Extend the enablepci method to have a "poweroff" flag, which if equal
to true means the hardware is about to go to sleep.

Prepare for improved (read: pcie) suspend/resume support.

* Flesh out the pcie disable method for 11n chips, as they were defaulting
to the AR5212 (empty) PCIe disable method.

* Add accessor macros for the HAL PCIe enable/disable calls.

* Call disable on ath_suspend()

* Call enable on ath_resume()

NOTE:

* This has nothing to do with the NIC sleep/run state - the NIC still
will stay in network-run state rather than supporting network-sleep
state. This is preparation work for supporting correct suspend/resume
WARs for the 11n PCIe NICs.

TODO:

* It may be feasible at this point to keep the chip powered down during
initial probe/attach and only power it up upon the first configure/reset
pass. This however would require correct (for values of "correct")
tracking of the NIC power configuration state from the driver and that
just isn't attempted at the moment.

Tested:

* AR9280 on my Lenovo T60, but with no suspend/resume pass (yet).

"Upgrade" the AR9285 code to support PCI/ART EEPROM on flash.

I've just verified that this boots on an Atheros AP91. I haven't verified
it with traffic though, so YMMV.

Fix a corner case in the HAL debugging changes, where ah was NULL.

Although I tried to fix this earlier by introducing HALDEBUG_G(), it
turns out there seem to be other cases where the pointer value is still
NULL.

* Fix DO_HALDEBUG() and the HALDEBUG macro to check whether ah is NULL
before deferencing it
* Remove HALDEBUG_G() as it's no longer needed

This is hopefully a merge candidate for 9.0-RELEASE as enabling
debugging at startup could result in a kernel panic.

Undo this for now. It's "right", but it means everything will rely on
the ar9130 code.

Since at least one kernel config specifies individual ath HAL chips
rather than just "device ath_hal" (arm/AVILA), I'm doing this so people
aren't caught out when they update to -HEAD or 9.0 and discover their
ath setup doesn't compile.

I'll revisit this with a proper fix sometime before 9.0-RELEASE.

Approved by: re (kib, blanket)
Pointed out by: ray@
Pointy hat to: adrian@

Add in a dirty hack that allows for AR9280/AR9285/AR9287 embedded
systems, in the same way that AR9130 embedded systems work.

This isn't -everything- that is required - the PCI glue still
needs to be taught about the eepromdata hint, along the same
lines as the AHB glue.

Approved by: re (kib, blanket)

Break out the PLL setup into (mostly) per-chip methods, rather than
polluting the AR5416 code with later chipset support.

Note: ar9280InitPLL() supports Merlin (AR9280) and later (AR9285, AR9287.)

Submitted by: ssgriffonuser@gmail.com
Approved by: re (kib)

Re-introduce a global ath_hal_debug again for now, whilst I figure out what
to do about the few cases where the HAL state isn't available (regdomain)
or isn't yet setup (probe/attach.)

The global ath_hal_debug now affects all instances of the HAL.

This also restores the ability for probe/attach debugging to work; as
the sysctl tree may not be attached at that point. Users can just set
the global "hw.ath.hal.debug" to a suitable value to enable probe/attach
related debugging.

Add some missing DFS chipset functionality to the FreeBSD HAL.

Please note - this doesn't in any way constitute a full DFS
implementation, it merely adds the relevant capability bits and
radar detection threshold register access.

The particulars:

* Add new capability bits outlining what the DFS capabilities
are of the various chipsets.
* Add HAL methods to set and get the radar related register values.
* Add AR5212 and AR5416+ DFS radar related register value
routines.
* Add a missing HAL phy error code that's related to radar event
processing.
* Add HAL_PHYERR_PARAM, a data type that encapsulates the radar
register values.

The AR5212 routines are just for completeness. The AR5416 routines
are a super-set of those; I may later on do a drive-by pass to
tidy up duplicate code.

Obtained from: Linux, Atheros

Tidy up the ANI API in preparation for looking to expose some more
of the ANI statistics and committing some tools which use these.

* Change HAL_ANI_* commands _back_ to be numerical, rather than a
bitmap;
* modify access to the ANI control bitmap to convert a command to
a bitmap;
* Fix the ANI noise immunity fiddling for CCK errors - it wasn't
checking whether noise immunity was disabled or not.

AR9285 (Kite) fixes.

* Correct some of the silicon revision checks to match what
the Atheros HAL does. (See [1] below.)

* Move the PA cal and init cal method assignment to -after-
the mac version/revision IDs are stored. The AR9285 init
cal was never being called.

* Enable ANI.

Note Kite 1.0 and 1.1 were prototypes that shouldn't be seen
in the wild. Linux ath9k simply removed the prototype code from
their codebase. I'm going to leave it in there for now but
make it conditionally compilable in the future.

Obtained from: Atheros

Disable TX STBC - it isn't used for now, but it isn't supported on Kite.

Import some initial Kite fixed diversity code from Atheros.

For now, the diversity settings are controlled by 'txantenna',
-not- rxantenna. This is because the earlier chipsets had
controllable TX diversity; the RX antenna setting twiddles
the default antenna register. I'll try sort that stuff out at
some point.

Call the antenna switch function from the board setup function
so scans, channel changes, mode changes, etc don't set the
diversity back to a default state too far from what's intended.

Things to todo:

* Squirrel away the last antenna diversity/combining parameters
and restore them during board setup if HAL_ANT_VARIABLE is
defined. That way scans, etc don't reset the diversity settings.

* Add some more public facing statistics, rather than what's
simply logged under HAL_DEBUG_DIVERSITY.

For now, the fixed antenna settings behave better than variable
settings for me. I have some further fiddling to do..

Obtained from: Atheros

Do a HAL capabilities sync pass based on the Atheros HAL.

* Shuffle some of the capability numbers around to match the
Atheros HAL capability IDs, just for consistency.

* Add some new capabilities to FreeBSD from the Atheros
HAL which will be be shortly used when new chipsets are added
(HAL SGI-20 support is for Kiwi/AR9287 support); for
TX aggregation (MBSSID aggregate support, WDS aggregation
support); CST/GTT support for carrier sense/TX timeout.

Read in the extended regulatory domain flags so future code can use them.

These describe FCC/Japan channel and DFS behaviour.

The AR9285 and later chips don't set these bits in the eeprom, the correct
behaviour is to just assume all five bits are enabled.

Don't do Kite antenna switch selection this way (for now); antenna
diversity is done elsewhere now.

Add in the last bit of the HAL support for Kite diversity.

* add a new method, specifically for doing per-RX packet
antenna diversity
* set that HAL method only if it's Kite and a Kite chip that
does diversity.

Commit missing bits from the last commit:

* add the hal capability flag
* make sure its disabled for the ar9280/ar9285.

Introduce hardware PS-POLL support in the HAL.

Linux ath9k only enables this for AR9280 and later NICs; so
create a capability for it so it isn't enabled for earlier
NICs.

Enabling hardware PS-POLL support will come in a later commit
and will be disabled by default.

Even though it's very unlikely the misc mode register setting at -attach-
would be a problem, make sure it isn't overwritten by whatever is in
there at cold reset.

This brings the > ar5416 init path treatment of AR_MISC_MODE.

Port over the AR9285 PA calibration and initial calibration code from
Linux ath9k.

The ath9k ar9002_hw_init_cal() isn't entirely clear about what
is supposed to be called for what chipsets, so I'm ignoring the
rest of it and just porting the AR9285 init cal path as-is and
leaving the rest alone. Subsequent commits may also tidy up the
Merlin (AR9285) and other chipset support.

Obtained from: Linux ath9k

Kite is a 1x1 stream device.

Port over ar5416OverrideIni() from ath9k ar5008_hw_override_ini().

* change the BB gating logic to explicitly define which chips are covered;
the ath9k method isn't as clear.
* don't disable the BB gating for now, the ar5416 initvals have it, and the
ar9160 initval sets it to 0x0. Figure out why before re-enabling this.
* migrate the Merlin (ar9280) applicable WAR from the Kite (ar9285) code
(which won't get called for Merlin!) and stuff it in here.

There's apparently a bug with Merlin (AR9280) and later chipsets where
putting descriptors (not buffers) across a 4k page boundary can cause issues.
I've not seen it in production myself but it apparently can cause problems.

So, in preparation for addressing this workaround, (re)-expose the particular
HAL capability bit which marks whether the chipset has support for cross-4k-
boundary transactions or not.

A subsequent commit will modify the descriptor allocation to avoid allocating
descriptor entries that straddle a 4k page boundary.

Call the correct ANI Attach routine.

Add a new capability which reports the number of spatial streams a device supports.

The higher levels (net80211, if_ath, ath_rate) need this to make correct
choices about what MCS capabilities to advertise and what MCS rates are
able to be TXed.

In summary:

* AR5416 - 2/3 antennas, 2x2 streams
* AR9160 - 2/3 antennas, 2x2 streams
* AR9220 - 2 antennas, 2x2 sstraems
* AR9280 - 2 antennas, 2x2 streams
* AR9285 - 2 antennas but with antenna diversity, 1x1 stream

Bring over some NF calibration changes from ath9k.

Each different radio chipset has a different "good" range of CCA
(clear channel access) parameters where, if you write something
out of range, it's possible the radio will go deaf.

Also, since apparently occasionally reading the NF calibration
returns "wrong" values, so enforce those limits on what is being
written into the CCA register.

Write a default value if there's no history available.

This isn't the case right now but it may be later on when "off-channel"
scanning occurs without init'ing or changing the NF history buffer.
(As each channel may have a different noise floor; so scanning or
other off-channel activity shouldn't affect the NF history of
the current channel.)

Add a check for the AR9285E; I have no idea what this is.

The only other changes in ath9k for the AR9285E revolve around sleep modes
which are not fully implemented here yet.

Include the device ids for the AR2427.

This is apparently an AR9285 with the 802.11n specific bits disabled.

This code is completely untested; I'm doing this in response to users
who wish to test the functionality out. It's likely as buggy as the
AR9285 support is in FreeBSD at the moment.

Push the non-AR5416 related stuff into chipset specific directories.

sys/dev/ath/ath_hal/ar5416/ is getting very crowded and further
commits will make it even more crowded. Now is a good time to
shuffle these files out before any more extensive work is done
on them.

Create an ar9003 directory whilst I'm here; ar9003 specific
chipset code will eventually live there.

Include the initial support for external EEPROMs.

The AR9100 at least doesn't have an external serial EEPROM
attached to the MAC; it instead stores the calibration data
in the normal system flash.

I believe earlier parts can do something similar but I haven't
experienced it first-hand.

This commit introduces an eepromdata pointer into the API but
doesn't at all commit to using it. A future commit will
include the glue needed to allow the AR9100 support code
to use this data pointer as the EEPROM.

Bring in a couple of fixes from the Linux ath9k related to chip hangs.
While there, try to make the register write pattern look like what's
done by ath9k.

MFC after: 3 days

Setup the correct RX/TX chainmask when we play with the antenna
settings.

MFC after: 1 week
Sponsored by: iXsystems, inc

Couple of suggestions from Sam regarding latest commit:
o rename the new variables to comply with the naming scheme
o move the new variables to an AR5212 specific struct
o use ahp when available
o revert to previous ts_flags check

Properly setup the TX FIFO threshold for AR5416 based chipsets,
including the AR9285. This seems to fix some users's problems.

Submitted by: Jorge Boncompte [DTI2] <jorge at dti2.net>

Bring back AR9285 support. This fixes most of the issues and should be
pretty usable.

MFC after: 1 month