Revert r330897:

This was intended to be a non-functional change. It wasn't. The commit
message was thus wrong. In addition it broke arm, and merged crypto
related code.

Revert with prejudice.

This revert skips files touched in r316370 since that commit was since
MFCed. This revert also skips files that require $FreeBSD$ property
changes.

Thank you to those who helped me get out of this mess including but not
limited to gonzo, kevans, rgrimes.

Requested by: gjb (re)

Partial merge of the SPDX changes

These changes are incomplete but are making it difficult
to determine what other changes can/should be merged.

No objections from: pfg

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

The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare
to this event, adding if_var.h to files that do need it. Also, include
all includes that now are included due to implicit pollution via if_var.h

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

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