- 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

Add a method to explicitly disable radar reporting if required.

Disable strong signal diversity when enabling radar pulse detection
for the AR5212 era NICs.

Remove the hard-coded AR5416-series parameters and instead use the
DFS parameters fetched from the HAL.

Check whether the specific chipset supports RADAR reporting before
enabling DFS; or some of the (unset) DFS methods may fail.

Tested:

* AR5210 (correctly didn't enable radar PHY reporting)
* AR5212 (correctly enabled radar PHY reporting w/ the correct default
parameters.)

TODO:

* Now that I have this capability check in place, I could remove the
(empty) DFS methods from AR5210/AR5211.
* Test on AR5416, AR9160, AR9280.

PR: kern/170904

In a complete lack of foresight on my part, my previous commit broke
the assumption that ath_softc doesn't change size based on build time
configuration.

I picked up on this because suddenly radar stuff didn't work; and
although the ath_dfs code was setting sc_dodfs=1, the main ath driver
saw sc_dodfs=0.

So for now, include opt_ath.h in driver source files. This seems like
the sane thing to do anyway.

I'll have to do a pass over the code at some later stage and turn
the radiotap TX/RX structs into malloc'ed memory, rather than in-line
inside of ath_softc. I'd rather like to keep ath_softc the same
layout regardless of configuration parameters.

Pointy hat to: adrian

Change the ath_dfs_process_phy_err() method to take an mbuf rather than
a buffer pointer.

For large radar pulses, the AR9130 and later will return a series of
FFT results for software processing. These can overflow a single 2KB
buffer on longer pulses. This would result in undefined buffer behaviour.

Contribute some example code which demonstrates how to initialise the
radar parameters for the AR5416 and later NICs.

These parameters have been tested on the following NICs:

* AR5416
* AR9160
* AR9220
* AR9280

And yes, these will return radar pulse parameters and (for AR9160 and later)
radar FFT information as PHY errors.

This is again not enough to do radar detection, it's just here to faciliate
development and validation of radar detection algorithms.

The (pulse, not FFT) decoding code for AR5212, AR5416 and later NICs exist
in the HAL.

This code is disabled for now as generating radar PHY errors can quickly
cause issues in busy environment.s Some further debugging of the RX path
is needed.

Finally, these parameters are likely not useful for the AR5212 era NICs.
The madwifi-dfs branch should have suitable example parameters for the
11a era NICs.

Oops, commit a missing implementation change.

Whilst I'm here, add a comment about what would happen in this function
if hypothetically you had a radar pattern matching detector written.

- change "is is" to "is" or "it is"
- change "the the" to "the"

Approved by: lstewart
Approved by: sahil (mentor)
MFC after: 3 days

Remove the now unneeded references to these DFS methods.

Sorry for the noise everyone.

Approved by: re (kib, blanket)

Introduce some more DFS related hooks, inspired both by local work
and the Atheros reference code.

The radar detection code needs to know what the current DFS domain is.
Since net80211 doesn't currently know this information, it's extracted
from the HAL regulatory domain information.

The specifics:

* add a new ath_dfs API hook, ath_dfs_init_radar_filters(), which
updates the radar filters whenever the regulatory domain changes.
* add HAL_DFS_DOMAIN which describes the currently configured DFS domain .
* add a new HAL internal variable which tracks the currently configured
HAL DFS domain.
* add a new HAL capability, HAL_CAP_DFS_DMN, which returns the currently
configured HAL DFS domain setting.
* update the HAL DFS domain setting whenever the channel setting is
updated.

Since this isn't currently used by any radar code, these should all
be no-ops for existing users.

Obtained from: Atheros
Submitted by: KBC Networks, sibridge
Approved by: re (kib, blanket)

Fix incorrect error reporting during the dfs ioctl function.

Approved by: re (kib)

Implement a basic radar parameter API in the dfs_null module.

Since no actual radar data is ever handled, this won't
do anything. It's mostly here as a reference for those who
wish to experiment with radar detection.

Approved by: re (kib)

Commit radar detection changes missed by my previous commit.

Flesh out the radar detection related operations for the ath driver.

This is in no way a complete DFS/radar detection implementation!
It merely creates an abstracted interface which allows for future
development of the DFS radar detection code.

Note: Net80211 already handles the bulk of the DFS machinery,
all we need to do here is figure out that a radar event has occured
and inform it as such. It then drives the DFS state engine for us.

The "null" DFS radar detection module is included by default;
it doesn't require a device line.

This commit:

* Adds a simple abstracted layer for radar detection state -
sys/dev/ath/ath_dfs/;
* Implements a null DFS module which doesn't do anything;
(ie, implements the exact behaviour at the moment);
* Adds hooks to the ath driver to process received radar events
and gives the DFS module a chance to determine whether
a radar has been detected.

Obtained from: Atheros