MFC r303891, r303892:
sys: replace comma with semicolon when pertinent.

Uses of commas instead of a semicolons can easily go undetected. The comma
can serve as a statement separator but this shouldn't be abused when
statements are meant to be standalone.

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

dev/ath: minor spelling fixes in comments.

No functional change.

Reviewed by: adrian

Fix kernel build, broken in r290612

Approved by: adrian

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.

Return the correct HAL data type for HAL_DIAG_ANI_STATS.

I .. stupidly added code to return HAL_ANI_STATS to HAL_DIAG_ANI_STATS.
I discovered this in a noisy environment when the returned values were
enough to .. well, make everything terrible.

So - restore functionality.

Tested:

* AR5416 (uses the AR5212 HAL), in a /very/ noisy 2GHz environment.
Enough to trigger ANI to get upset and generate useful data.

Use the HAL API for returning ar5212AniState, rather than just dumping
AniState itself.

Start the process of migrating the ANI statistics out of the HALs and into
the top-level HAL.

The athstats program is blindly using a copy of the ar5212 ANI stats structure
to pull out ANI statistics/state and this is problematic for the AR9300
HAL.

So:

* Define HAL_ANI_STATS and HAL_ANI_STATE
* Use HAL_ANI_STATS inside the AR5212 HAL

This commit doesn't (yet) convert the ar5212AniState -> HAL_ANI_STATE when
exporting it to userland; that'll come in the next commit.

Move the HAL channel survey support out to be in the top-level HAL,
rathe than private in each HAL module.

Whilst here, modify ath_hal_private to always have the per-channel
noisefloor stats, rather than conditionally. This just makes
life easier in general (no strange ABI differences between different
HAL compile options.)

Add a couple of methods (clear/reset, add) rather than using
hand-rolled versions of things.

Fix the following -Werror warning from clang 3.5.0, while building the
ath kernel module:

sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: error: taking the absolute value of unsigned type 'unsigned int' has no effect [-Werror,-Wabsolute-value]
if (abs(lp[0] * EEP_SCALE - target) < EEP_DELTA) {
^
sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs'
#define abs(_a) __builtin_abs(_a)
^
sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: note: remove the call to '__builtin_abs' since unsigned values cannot be negative
sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs'
#define abs(_a) __builtin_abs(_a)
^
1 error generated.

This warning occurs because both lp[0] and target are unsigned, so the
subtraction expression is also unsigned, and calling abs() is a no-op.

However, the intention was to look at the absolute difference between
the two unsigned quantities. Introduce a small static function to
clarify what we're doing, and call that instead.

Reviewed by: adrian
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D1212

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

* Only update ah_powerMode if we're setting the chip sleep state.
Some code will appear soon that is actually setting the chip powerstate
separate from the self-generated frames power state.
* Allow the AR5416 family chips to actually have the power state changed
from the self generated state change.

Tested (STA mode):

* AR5210
* AR5211
* AR5412
* AR5413
* AR5416
* AR9285

Also set the AR5212 HAL power mode tracking in the right spot.

Tested:

* D-Link DWL-G650 NIC (AR2413), STA mode

Migrate the chip power mode status to public ath_hal, rather than the
private per-chip HAL.

This allows the ah_osdep.[ch] code to check whether the power state is
valid for doing chip programming.

It should be a no-op for normal driver work but it does require a
clean kernel/module rebuild, as the size of HAL structures have changed.

Now, this doesn't track whether the hardware is ACTUALLY awake,
as NETWORK_SLEEP wakes the chip up for a short period when traffic
is received. This doesn't actually set the power mode to AWAKE, so
we have to be careful about how we touch things.

But it's enough to start down the path of implementing station mode
chipset power savings, as a large part of the silliness is making
sure the chip is awake during periodic calibration / ANI and
random places where transmit may be occuring. I'd rather not a repeat
of debugging power save on ath9k, where races with calibration
and transmit path stuff took a couple years to shake out.

Tested:

* AR5416, STA mode

Add channel survey support to the AR5212 HAL.

The AR5212 series of MACs implement the same channel counters as the
later 11n chips - except, of course, the 11n specific counter (extension
channel busy.)

This allows users of these NICs to use 'athsurvey' to see how busy their
current channel is.

Tested:

* AR5212, AR2413 NICs, STA mode

Approved by: re@ (gleb)

Begin adding support to explicitly set the current chainmask.

Right now the only way to set the chainmask is to set the hardware
configured chainmask through capabilities. This is fine for forcing
the chainmask to be something other than what the hardware is capable
of (eg to reduce TX/RX to one connected antenna) but it does change what
the HAL hardware chainmask configuration is.

For operational mode changes, it (may?) make sense to separately control
the TX/RX chainmask.

Right now it's done as part of ar5416_reset.c - ar5416UpdateChainMasks()
calculates which TX/RX chainmasks to enable based on the operating mode.
(1 for legacy and whatever is supported for 11n operation.) But doing
this in the HAL is suboptimal - the driver needs to know the currently
configured chainmask in order to correctly enable things for each
TX descriptor. This is currently done by overriding the chainmask
config in the ar5416 TX routines but this has to disappear - the AR9300
HAL support requires the driver to dynamically set the TX chainmask based
on the TX power and TX rate in order to meet mini-PCIe slot power
requirements.

So:

* Introduce a new HAL method to set the operational chainmask variables;
* Introduce null methods for the previous generation chipsets;
* Add new driver state to record the current chainmask separate from
the hardware configured chainmask.

Part #2 of this will involve disabling ar5416UpdateChainMasks() and moving
it into the driver; as well as properly programming the TX chainmask
based on the currently configured HAL chainmask.

Tested:

* AR5416, STA mode - both legacy (11a/11bg) and 11n rates - verified
that AR_SELFGEN_MASK (the chainmask used for self-generated frames like
ACKs and RTSes) is correct, as well as the TX descriptor contents is
correct.

When programming the beacon timer configuration, be very explicit about
what the maximum legal values are.

The current beacon timer configuration from TDMA wraps things at
HAL_BEACON_PERIOD-1 TU. For the 11a chips this is fine, but for
the 11n chips it's not enough resolution. Since the 11a chips have a
limit on what's "valid", just enforce this so when I do write larger
values in, they get suitably wrapped before programming.

Tested:

* AR5413, TDMA slave

Todo:

* Run it for a (lot) longer on a clear channel, ensure that no strange
slippages occur.
* Re-validate this on STA configurations, just to be sure.

Implement a HAL method to set a 64 bit TSF value.

TODO: implement it (and test) for the AR5210/AR5211.

.. include ah_desc.h here now.

Remove the ah_desc.h reference; it's not needed.

I'm using these descriptor header files in userland and I'm trying to
avoid populating a compatibility ah_desc.h file.

Remove duplicate const specifiers in many drivers (I hope I got all of
them, please let me know if not). Most of these are of the form:

static const struct bzzt_type {
[...list of members...]
} const bzzt_devs[] = {
[...list of initializers...]
};

The second const is unnecessary, as arrays cannot be modified anyway,
and if the elements are const, the whole thing is const automatically
(e.g. it is placed in .rodata).

I have verified this does not change the binary output of a full kernel
build (except for build timestamps embedded in the object files).

Reviewed by: yongari, marius
MFC after: 1 week

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

AR5212 radar pulse fixes.

Fix the strong signal diversity capability setting - I had totally
messed up the indentation.

Set the default values to match what's in the .ini for now, rather than
what values I had previously gleaned from places. This seems to work
quite well for the early AR5212 NICs I have. Of course, later NICs
have different PHYs and the radar configuration is very card/board
dependent..

Tested:

* ath1: AR5212 mac 5.3 RF5111 phy 4.1
ath1: 2GHz radio: 0x0023; 5GHz radio: 0x0017

This detects 1, 5, 25, 50, 75, 100uS pulses reliably (with no interference.)

However, 10uS pulses don't detect reliably. That may be around the
transition between short and long pulses so some further tuning may
improve things.

Fix the PHY / CRC error bug in the AR5212 HAL, which apparently also pops
up on (at least) the AR5413.

The 30 second summary - if a CRC error frame comes in during PHY error
processing, that CRC bit will be set for all subsequent frames until
a non-CRC error frame is processed.

So to allow for accurate PHY error processing (Radar, and ANI on the AR5212
HAL chips) just tag the frame as being both CRC and PHY - let the driver
decide what to do with it.

PR: kern/169362

Add AR5413 radar parameters and strong signal diversity capability.

This is a re-implementation based on the reference carrier code
for the AR5413.

Tested:
* Pulse detection for AR5212 and AR5413, to ensure the
correct behaviour for both chips

PR: kern/170904
Obtained from: Qualcomm Atheros

Correctly handle the "pe_enabled" flag - both when configuring DFS and
fetching the current DFS configuration.

PR: kern/170904

Add default values for the NumTxMaps capability.

Add the method to fetch the default DFS parameters for the AR5212 PHY.

I need to check whether new parameters were added for the AR5413 NIC.

PR: kern/170904

Migrate the ath_hal_filltxdesc() API to take a list of buffer/seglen values.

The existing API only exposes 'seglen' (the current buffer (segment) length)
with the data buffer pointer set in 'ds_data'. This is fine for the legacy
DMA engine but it won't work for the EDMA engines.

The EDMA engine has a significantly different TX descriptor layout.

* The legacy DMA engine had a ds_data pointer at the same offset in the
descriptor for both TX and RX buffers;
* The EDMA engine has no ds_data for RX - the data is DMAed after the
descriptor;
* The EDMA engine has support for 4 TX buffer/segment pairs in the TX
DMA descriptor;
* The EDMA TX completion is in a different FIFO, and the driver will
'link' the status completion entry to a QCU by a "QCU ID".
I don't know why it's just not filled in by the hardware, alas.

So given that, here are the changes:

* Instead of directly fondling 'ds_data' in ath_desc, change the
ath_hal_filltxdesc() to take an array of buffer pointers as well
as segment len pointers;
* The EDMA TX completion status wants a descriptor and queue id.
This (for now) uses bf_state.bfs_txq and will extract the hardware QCU
ID from that.
* .. and this is ugly and wasteful; it should change to just store
the QCU in the bf_state and save 3/7 bytes in the process.

Now, the weird crap:

* The aggregate TX path was using bf_state->bfs_txq for the TXQ, rather than
taking a function argument. I've tidied that up.
* The multicast queue frames get put on a software TXQ and then that is
appended to the hardware CABQ when appropriate. So for now, make sure
that bf_state->bfs_txq points at the CABQ when adding frames to the
multicast queue.
* .. but the multicast queue TX path for now doesn't use the software
queue and instead
(a) directly sets up the descriptor contents at that point;
(b) the frames on the vap->avp_mcastq are then just appended wholesale
to the CABQ.
So for now, I don't have to worry about making the multicast path
work with aggregation or the per-TID software queue. Phew.

What's left to do:

* I need to modify the 11n ath_hal_chaintxdesc() API to do the same.
I'll do that in a subsequent commit.
* Remove bf_state.bfs_txq entirely and store the QCU as appropriate.
* .. then do the runtime "is this going on the right HWQ?" checks using
that, rather than comparing pointer values.

Tested on:

* AR9280 STA/AP
* AR5416 STA/AP

Flesh out the multi-rate retry capability.

The existing method for testing for MRR is to call the "SetupXTXDesc"
HAL method and see if it returns AH_TRUE or AH_FALSE. This capability
explicitly lists what number of multi-rate attempts are possible.

"1" means "one rate attempt supported".

Break out the TX descriptor link field into HAL methods.

The DMA FIFO chips (AR93xx and later) differ slightly to th elegacy
chips:

* The RX DMA descriptors don't have a ds_link field;
* The TX DMA descriptors have a ds_link field however at a different
offset.

This is a reimplementation based on what the reference driver and ath9k
does.

A subsequent commit will enable it in the TX and beacon paths.

Obtained from: Linux ath9k, Qualcomm Atheros

Extend the RX HAL API to include the RX queue identifier.

The AR93xx and later chips support two RX FIFO queues - a high and low
priority queue.

For legacy chips, just assume the queues are high priority.

This is inspired by the reference driver but is a reimplementation of
the API and code.

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.

Change the MIB cycle count API to return HAL_BOOL, rather than uint32_t,
to return whether it was successful.

Add placeholder (blank) methods for previous chips, for both it and
the 11n extension channel busy call.

After thinking about this a bit more, let's not keep statistics per-channel
in the HAL. That's very memory hungry (32k just for channel statistics)
which would be better served by keeping a summary in the ANI state.

Or, later, keep a survey history in net80211.

So:

* Migrate the ah_chansurvey array to be a single entry, for the current
channel.
* Change the ioctl interface and ANI code to just reference that.
* Clear the ah_chansurvey array during channel reset, both in the AR5212
and AR5416 reset path.

Fetch the channel survey code from the HAL.

This information is currently not being populated by any of the HAL
modules.

Stop using the hardware register value byte order swapping for now,
at least until I can root cause what's going on.

The only platform I've seen this on is the AR9220 when attached to
the AR71xx CPUs. I get immediate PCIe bus errors and all subsequent
accesses cause further MIPS bus exceptions. I don't have any other
big-endian platforms to test this on.

If I get a chance (or two), I'll try to whack this on a bus analyser
and see exactly what happens.

I'd rather leave this on, especially for slower, embedded platforms.
But the #ifdef hell is something I'm trying to avoid.

Radar API related fixes.

* For legacy NICs, the combined RSSI should be used.
For earlier AR5416 NICs, use control chain 0 RSSI rather than combined
RSSI.
For AR5416 > version 2.1, use the combined RSSI again.

* Add in a missing AR5212 HAL method (get11nextbusy) which may be called
by radar code.

This serves no functional change for what's currently in FreeBSD.

Use the correct types when calling the decompression mask function.

There's currently no public code which uses this feature and the
current reference driver doesn't enable this feature at all.
It's possible it was used by a previous version of the driver and
that indeed it should return HAL_STATUS; but at this point I'm
happy to require that they complain and submit a patch.

This was found by LLVM compile-time type checking.

Submitted by: dim

Revert r228786. We'll need to work around the warnings in another way.

Requested by: adrian
MFC after: 1 week

Fix enum conversion problems in sys/dev/ath/ath_hal/ar5212/ar5212_misc.c
and sys/dev/ath/ath_hal/ar5416/ar5416_misc.c:

sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:577:24: warning: implicit conversion from enumeration type 'HAL_STATUS' to different enumeration type 'HAL_BOOL' [-Wconversion]
return HAL_EINVAL;
~~~~~~ ^~~~~~~~~~

and:

sys/dev/ath/ath_hal/ar5416/ar5416_misc.c:164:9: warning: implicit conversion from enumeration type 'HAL_STATUS' to different enumeration type 'HAL_BOOL' [-Wconversion]
return HAL_OK;
~~~~~~ ^~~~~~

In both cases, enums HAL_BOOL and HAL_STATUS are mixed up.

MFC after: 1 week

The AR5413 datasheet specifies that AR_TxIntrReq should be set consistently
for all frames, so do so.

Save and restore the association ID across interface resets.

Obtained from: Atheros
MFC after: 1 week

Port over some missing code from the ar5212 reference driver reset path.

The final missing bit here is enabling the PCI configuration register
read, but there's currently no glue available for the HAL to read (and
write) PCI configuration space registers.

Obtained from: Atheros

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.

Change the default CABQ time to be 70% of the beacon interval,
rather than the whole beacon interval.

The reference driver and Linux ath9k both choose 80% of the
beacon interval and they do it in the driver rather than
the HAL (Ath reference) or ath9k_hw (ath9k.)

This quietens stuck beacon conditions on my AR9220/AR9280
based NICs when a lot of burst broadcast/multicast traffic
is going on. It doesn't seem to annoy the earlier MACs as
much as the AR9280 and later one.

Obtained from: Linux ath9k, Atheros

The AR5212 setup path (also used by the AR5416 code) configures a
local variable with a beacon interval of 100 TU. This never gets modified
if the beacon interval configuration changes.

This may have been correct in earlier times, but with the advent of
staggered beacons (which default to 1 / ATH_BCBUF beacon interval, so
25 TU here) this value is incorrect.

It is used to configure the default CABQ readytime. So here, the cabq
was being configured to be much greater than the target beacon timer
(TBTT.)

The driver should be configuring a cabq readytime value rather then
leaving it to the HAL to choose sensible defaults. This should be
done in the future - I'm simply trying to ensure sensible defaults
are chosen.

Update the TSF and next-TBTT methods to work for the AR5416 and later NICs.
This is another commit in a series of TDMA support fixes for the 11n NICs.

* Move ath_hal_getnexttbtt() into the HAL; write methods for it.
This returns a timer value in TSF, rather than TU.

* Move ath_hal_getcca() and ath_hal_setcca() into the HAL too, where they
likely now belong.

* Create a new HAL capability: HAL_CAP_LONG_RXDESC_TSF.
The pre-11n NICs write 15 bit TSF snapshots into the RX descriptor;
the AR5416 and later write 32 bit TSF snapshots into the RX descriptor.
* Use the new capability to choose between 15 and 31 bit TSF adjustment
functions in ath_extend_tsf().

* Write ar5416GetTsf64() and ar5416SetTsf64() methods.
ar5416GetTsf64() tries to compensate for TSF changes at the 32 bit boundary.

According to yin, this fixes the TDMA beaconing on 11n chipsets and TDMA
stations can now associate/talk, but there are still issues with traffic
stability which need to be investigated.

The ath_hal_extendtsf() function is also used in RX packet timestamping;
this may improve adhoc mode on the 11n chipsets. It also will affect the
timestamps seen in radiotap frames.

Submitted by: Kang Yin Su <cantona@cantona.net>
Approved by: re (kib)

Add another HAL method - ah_isFastClockEnabled - which returns AH_TRUE
if 5ghz fast clock is enabled in the current operating mode.

It's slightly dirty, but it's part of the reference HAL and used by
the (currently closed-source) radar event code to map radar pulses
back to microsecond durations.

Obtained from: Atheros
Approved by: re (kib, blanket)

Fix ANI handling to work correctly when (trying) to receive radar errors.

* Teach the AR5212/AR5416 ANI code to use the RX filter methods, rather
than calling the RX filter routines directly.

* Make HAL_ANI_PRESENT and HAL_ANI_MODE unconditionally available,
regardless of whether ah_ani_function is masking it.

* (Mostly) fully disable ANI if interference mitigation is disabled.
When disabled, the ANI code doesn't touch any ANI/PHY registers,
leaving them the default value. This is in line with what the
Atheros reference driver does.

* Correctly set the ANI parameters during ANI reset, rather than
when ANI is enabled. In this way, if ANI is disabled or enabled
whilst the NIC is not active (and there's no current channel),
bogus parameters or a NULL pointer deference doesn't occur.

There's still some lingering issues - notably, the MIB events/interrupts
aren't fully disabled, so MIB interrupts still occur. I'll worry about
that later.

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.

Fix indenting issues introduced by the previous commit.

Break out most of the HAL related tweaks into a per-HAL instance,
rather than global variables.

This specifically allows for debugging to be enabled per-NIC, rather
than globally.

Since the ath driver doesn't know about AH_DEBUG, and to keep the ABI
consistent regardless of whether AH_DEBUG is enabled or not, enable the
debug parameter always but only conditionally compile in the debug
methods if needed.

The ALQ support is currently still global pending some brainstorming.

Submitted by: ssgriffonuser@gmail.com
Reviewed by: adrian, bschmidt

Since HAL_PHYERR_* is used in the radar code, always include ah_desc.h.

Flesh out a new HAL method to fetch the radar PHY error frame information.

For the AR5211/AR5212, this is apparently a one byte pulse duration
counter value. It is only coded up here for the AR5212 as I don't have
any AR5211-series hardware to test it on.

This information was extracted from the Madwifi DFS branch along with
some local additions.

Please note - all this does is extract out the radar event duration,
it in no way reflects the presence of a radar. Further code is needed
to take a set of radar events and filter them to extract out correct
radar pulse trains (and ignore other events.)

For further information, please see:

http://wiki.freebsd.org/dev/ath_hal%284%29/RadarDetection

This includes references to the relevant patents which describe what
is going on.

Obtained from: Madwifi

Bring over the relevant registers to use when implementing the quiet time
portion of 802.11h.

The AR5212 code has been brought over as a reference, it's currently
untested.

Obtained from: Atheros

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

The current ANI capability information uses a different set of
values for the commands, compared to the internal command values
(HAL_ANI_CMD.)

My eventual aim is to make the HAL_ANI_CMD internal enum match
the public API and then remove all this messiness.

This now allows HAL_CAP_INTMIT users to use a public HAL_CAP_INTMIT_
enum rather than magic constants.

The only magic constants currently used by if_ath are "enable" and
"present". Some local tools of mine allow for direct, manual fiddling
of the ANI variables and I'll convert these to use the public enum API
before I commit them.

The ANI control for the AR5416 and later chips was calling ar5212AniControl(),
which did AR5212 specific initialisation. This would cause some slight
silliness when enabling/disabling ANI.

Just to be completely correct - and to ensure the phy error mask/RX filter
register isn't incorrectly played with - make the ANI control function a
method, have it set appropriately for AR5212/AR5416, and call that from the
ANI control interface.

Fix case, introduced in my previous commit.

Pointy hat goes to: adrian, for having multiple build screens
open and checking the wrong one.

Use the halMcastKeySrchSupport capability bit to selectively enable/disable
the multicast key search support for AR5212, AR5416 and later.

The general HAL routine ath_hal_getcapability() implement checking this
but it's overridden by a check in ar5212_misc:ar5212GetCapability().
This restores the later functionality in case it's found to be broken
in any of the 11n chipsets.

Add some more OS_MARK probes to the RX DMA setup/teardown code path.

I'm trying to debug the RX DMA path and help the ath9k guys with
"RX dma abort stuck" issue that both our drivers have.

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.

Make sure that the AR_MISC_MODE value from the initvals are properly respected.

This commit really is "fix the OFDM duration calculation to match reality when
running in 802.11g mode."

The AR5212 init vals set AR_MISC_MODE to 0x0 and all the bits that can be set are
set through code.

The AR5416 and later initvals set AR_MISC_MODE to various other values (with
the AR5212 AR_MISC_MODE options cleared), which include AR_PCU_CCK_SIFS_MODE .
This adds 6uS to SIFS on non-CCK frames when transmitting.

This fixes the issue where _DATA_ 802.11g OFDM frames were being TX'ed with
the ACK duration set to 38uS, not 44uS as on the AR5212 (and other devices.)

The AR5212 TX pathway obeys the software-programmed duration field in the packet,
but the 11n TX pathway overrides that with a hardware-calculated duration. This
was getting it wrong because of the above AR_MISC_MODE setting. I've verified
that 11g data OFDM frames are now being TXed with the correct ACK+SIFS duration
programmed in.

For chips that are full reset in ar5416ChipReset(), save and restore the TSF.

Merlin (ar9280) and later were full-reset if they're doing open-loop TX
power control but the TSF wasn't being saved/restored.

Add ar5212SetTsf64() which sets the 64 bit TSF appropriately.

Fix the keycache behaviour for multicast keycache search.

The correct bit to set is 0x1 in the high MAC address byte, not 0x80.
The hardware isn't programmed with that bit (which is the multicast
adress bit.)

The linux ath9k keycache code uses that bit in the MAC as a "this is
a multicast key!" and doesn't set the AR_KEYTABLE_VALID bit.
This tells the hardware the MAC isn't to be used for unicast destination
matching but it can be used for multicast bssid traffic.

This fixes some encryption problems in station mode.

PR: kern/154598

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.

Fix typo in SIFS setup

Make space for the extended 802.11n MCS rate tables.

ANI changes #1 - split out the ANI polling from the RxMonitor hook.

The rxmonitor hook is called on each received packet. This can get very,
very busy as the tx/rx/chanbusy registers are thus read each time a packet
is received.

Instead, shuffle out the true per-packet processing which is needed and move
the rest of the ANI processing into a periodic event which runs every 100ms
by default.

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.

Add a new HAL method to retrieve the completion schedule. It sets
the completion schedule from the hardware and returns AH_TRUE if
the hardware supports multi-rate retries (AR5212 and above); and
returns AH_FALSE if the hardware doesn't support multi-rate retries.

The sample rate module directly reads the TX completion descriptor
and extracts the TX schedule information from that. It will be
updated in a future commit to instead use this method to determine
the completion schedule.

Add a couple of functions to check NF calibration progress / completion.

The Atheros AR71xx CPUs, when paired with the AR5212 parts, has a bug
that generates a fatal bus trap. Normally, the chips are setup to do
128 byte DMA bursts, but when on this CPU, they can only safely due
4-byte DMA bursts due to this bug. Details of the exact nature of the
bug are sketchy, but some can be found at
https://forum.openwrt.org/viewtopic.php?pid=70060 on pages 4, 5 and 6.
There's a small performance penalty associated with this workaround,
so it is only enabled when needed on the Atheros AR71xx platforms.

Unfortunately, this condition is impossible to detect at runtime
without MIPS specific ifdefs. Rather than cast an overly-broad net
like Linux/OpenWRT dues (which enables this workaround all the time on
MIPS32 platforms), we put this option in the kernel for just the
affected machines. Sam didn't like this aspect of the patch when he
reviewed it, and I'd love to hear sane proposals on how to fix it :)

Reviewed by: sam@

Introduce ath_hal_setInterrupts(), a macro for ah_setInterrupts().

Pointed out by: sam

Replace Id keyword with FreeBSD keyword and set the svn props correctly.
No functional change.

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>

Add support for the AR9285 chipset, which is found on many netbooks
available today.

This card is a low power 802.11bgn that only does 11n rates up to MCS 7
(that's 65 Mbps in 20Mhz mode and 135 in 40Mhz mode).
802.11n is not yet supported, but will be in the future.

The driver still has a problem regarding to the setting of txpower on
the card, so don't expect good performance yet. After fixing this
problem, an MFC is possible.

Special thanks to iXsystems and S Smirnov <tonve at yandex.ru> for help
with the purchase of a netbook with this card.

Sponsored by: iXsystems, Inc.

Remove extraneous semicolons, no functional changes.

Submitted by: Marc Balmer <marc@msys.ch>
MFC after: 1 week

Fix handling of AR_RX_FILTER_BSSID: write the shadow value for AR_MISC_MODE
so other register writes preserve the setting of AR_MISC_MODE_BSSID_MATCH_FORCE.

Reviewed by: rpaulo
Approved by: re (kib)

Add HAL_RX_FILTER_BSSID support (to disable bssid match):
o add HAL_CAP_BSSIDMATCH to identify parts that have the support for
disabling bssid match
o honor capability for set/get rx filter
o use HAL_CAP_BSSIDMATCH in driver to decide whether to use the bssid
match disable or fall back to promisc mode

Reviewed by: rpaulo
Approved by: re (rwatson)

purge HAL_TXSTAT_ALTRATE; you can figure this out by checking ts_finaltsi
and it cannot be used with MCS rate codes

add TBTT interrupt support; this was added in Griffin so consumers should
check HAL_CAP_INTRMASK before using it

NB: didn't test 11n parts yet so supported only for 5212-class parts

minor cleanup

remove special handling for BNR; it is direct mapped to the harwdare so
can be added to HAL_INT_COMMON except on the 5210 where it doesn't exist

add HAL_CAP_INTRMASK to return the set of interrupts supported by the device

add support for the Beacon Not Ready (BNR) interrupt
(available on 5211 and later)

o eliminate a << in calculating the tx time for turbo mode by pre-multiplying
data in the phy tables
o correct the ctrl rate indices in the 5212 turbog phy table

purge hal abi support; now that the hal is merged w/ the driver
we cannot be out of sync

MFC after: 1 week

Add PCIE power control api:
o add ah_configPCIE and ah_disablePCIE for drivers to configure PCIE
power save operation (modeled after ath9k, may need changes)
o add private state flag to indicate if device is PCIE (replaces private
hack in 5212 code)
o add serdes programming ini bits for 5416 and later parts and setup
for each part (5416 and 9160 logic hand-crafted from existing routines);
5212 remains open-coded but is now hooked in via ah_configPCIE
o add PCIE workaround gunk
o add ar5416AttachPCIE for iodomatic code used by 5416 and later parts

5416 and later parts mux the gpio outputs; extend the api to include
a signal type that's used to select the appropriate mux

remove private copies of gpio methods that were needed when the hal
was an independent entity

correct SIFS setting; there is a 2usec adjustment between the calculated
value and what the hardware requires (based on inspection of INI values)

Submitted by: Jiri Fojtasek <jiri.fojtasek@hlohovec.net>

Cleanup ath_hal_computetxtime's handling of 1/2 and 1/4-width channels:
o mark phy type to indicate 1/2 or 1/4-rate operation
o use phy type instead of channel attributes to identify 1/2 and 1/4-rate
operation
o general cleanup of code including move phy constants to ah_internal.h

Eventually this code should go away and we should use the net0211 equivalents.

consolidate conditional code

eliminate gainFCorrection; just have ar5212GetGainFCorrection return
the calculated value as it's only used in one place

improve IQ cal debug msgs; in particular don't scare people by screaming
"MISGATED IQ CAL!" when it's not

fill in ar5212ResetCalValid; reset the IQ valid flag on the channel
so IQ calibration will be started on the next periodic cal

style

replace r/w idiom with OS_REG_SET_BIT (to match other code)

o make SAVE_CCK slightly less error prone by always writing the _flag
value used later by RESTORE_CCK
o swap arg order in RESTORE_CCK to slightly reduce cost

restore variable initialization removed in r187831; this broke
the horrible SAVE/RESTORE_CCK macros used by swan/nala cards to
implement 11b using 11g

Overhaul regulatory support:
o remove HAL_CHANNEL; convert the hal to use net80211 channels; this
mostly involves mechanical changes to variable names and channel
attribute macros
o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant
with the net80211 channel available
o change api for ath_hal_init_channels: no more reglass id's, no more outdoor
indication (was a noop), anM contents
o add ath_hal_getchannels to have the hal construct a channel list without
altering runtime state; this is used to retrieve the calibration list for
the device in ath_getradiocaps
o add ath_hal_set_channels to take a channel list and regulatory data from
above and construct internal state to match (maps frequencies for 900MHz
cards, setup for CTL lookups, etc)
o compact the private channel table: we keep one private channel
per frequency instead of one per HAL_CHANNEL; this gives a big
space savings and potentially improves ani and calibration by
sharing state (to be seen; didn't see anything in testing); a new config
option AH_MAXCHAN controls the table size (default to 96 which
was chosen to be ~3x the largest expected size)
o shrink ani state and change to mirror private channel table (one entry per
frequency indexed by ic_devdata)
o move ani state flags to private channel state
o remove country codes; use net80211 definitions instead
o remove GSM regulatory support; it's no longer needed now that we
pass in channel lists from above
o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A
o simplify initial channel list construction based on the EEPROM contents;
we preserve country code support for now but may want to just fallback
to a WWR sku and dispatch the discovered country code up to user space
so the channel list can be constructed using the master regdomain tables
o defer to net80211 for max antenna gain
o eliminate sorting of internal channel table; now that we use ic_devdata
as an index, table lookups are O(1)
o remove internal copy of the country code; the public one is sufficient
o remove AH_SUPPORT_11D conditional compilation; we always support 11d
o remove ath_hal_ispublicsafetysku; not needed any more
o remove ath_hal_isgsmsku; no more GSM stuff
o move Conformance Test Limit (CTL) state from private channel to a lookup
using per-band pointers cached in the private state block
o remove regulatory class id support; was unused and belongs in net80211
o fix channel list construction to set IEEE80211_CHAN_NOADHOC,
IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT
o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are
now set in the constructed net80211 channel
o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one
of the driver-private flag bits of the net80211 channel
o move 900MHz frequency mapping into the hal; the mapped frequency is stored
in the private channel and used throughout the hal (no more mapping in the
driver and/or net80211)
o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the
calculation and available in the net80211 channel
o change noise floor calibration logic to work with compacted private channel
table setup; this may require revisiting as we no longer can distinguish
channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used
only to calculate status data we can live with it for now
o change ah_getChipPowerLimits internal method to operate on a single channel
instead of all channels in the private channel table
o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency
(always the same except for 900MHz channels)
o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory
problems
o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now
o change ath_hal_getwirelessmodes to really return wireless modes supported
by the hardware (was previously applying regulatory constraints)
o return channel interference status with IEEE80211_CHANSTATE_CWINT (should
change to a callback so hal api's can take const pointers)
o remove some #define's no longer needed with the inclusion of
<net80211/_ieee80211.h>

Sponsored by: Carlson Wireless

fix return status handling by ar5XXXReset; this is the reason the
driver sometimes reports reset failed w/ status 0

correct typo that left programmed sifs time in the slot time
(to be applied on subsequent resets)

Submitted by: Jiri Fojtasek <jiri.fojtasek@hlohovec.net>

On some platforms touching the bb registers when the phy is powered
down will cause a fault. Check the phy power state before possibly
reading from the bb, this can happen as ar5212Reset intentionally
calls ar5212GetRfgain before bringing the bb out of reset (but we
do it here and not in the caller to guard against other possible uses).

add FreeBSD property

Correct 5212 ani support so that max noise immunity, spur immunity, and
step levels are used.

Noticed by: Jiri Fojtasek <jiri.fojtasek@hlohovec.net>
Reviewed by: rpaulo

fix static const order

Obtained from: netbsd

add missing break

Coverity ID: 4159

import ath hal

purge useless code

make code compile

add chip+rf names for debug msgs, showing compiled-in support, etc.

kill AH_DISABLE_WME stuff; it's been posible to do this from the
driver for a while

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