Commit Graph

13 Commits

Author SHA1 Message Date
Adrian Chadd
be7f7a955b Disable strong signal diversity when enabling radar pulse detection
for the AR5212 era NICs.
2012-09-02 05:01:10 +00:00
Adrian Chadd
b7005313dd 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
2012-08-24 17:39:57 +00:00
Adrian Chadd
c312fb4adc 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
2012-06-24 08:47:19 +00:00
Adrian Chadd
d77363ad5b 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.
2012-06-24 08:09:06 +00:00
Adrian Chadd
ab4343580d 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.
2012-02-06 20:23:21 +00:00
Adrian Chadd
bfa5e92751 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.
2012-01-28 22:24:59 +00:00
Eitan Adler
36daf0495a - change "is is" to "is" or "it is"
- change "the the" to "the"

Approved by:	lstewart
Approved by:	sahil (mentor)
MFC after:	3 days
2011-10-16 14:30:28 +00:00
Adrian Chadd
e69c2d83cf Remove the now unneeded references to these DFS methods.
Sorry for the noise everyone.

Approved by:	re (kib, blanket)
2011-08-09 15:46:52 +00:00
Adrian Chadd
8db87e4079 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)
2011-08-08 16:22:42 +00:00
Adrian Chadd
99271119d3 Fix incorrect error reporting during the dfs ioctl function.
Approved by:	re (kib)
2011-07-30 13:46:41 +00:00
Adrian Chadd
c5f2a23c79 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)
2011-07-22 09:39:49 +00:00
Adrian Chadd
6025dd9f0a Commit radar detection changes missed by my previous commit. 2011-06-04 08:24:58 +00:00
Adrian Chadd
48237774e4 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
2011-06-01 20:09:49 +00:00