[ath_hal] Add get/set NAV functions

The NAV (network allocation vector) register reflects the current MAC
tracking of NAV - when it will stay quiet before transmitting.

Other devices transmit their

[ath_hal] Add get/set NAV functions

The NAV (network allocation vector) register reflects the current MAC
tracking of NAV - when it will stay quiet before transmitting.

Other devices transmit their frame durations in their 802.11 PHY headers
and all devices that hear a frame - even if it's one in an encoding
they don't understand - will understand the low bitrate PHY header that
includes the frame duration. So, they'll set NAV to this value so
they'll stay quiet until the transmit completes.

Anyway, sometimes the PHY NAV header is garbled and sometimes, notably
older broadcom devices, will fake a long NAV so they can get "cleaner" air
for local calibration. When this happens, the hardware will stay quiet
for quite some time and this can lead to missed/stuck beacons, or
(for Very Large Values) a MAC hang.

This code just adds the ability to get/set the NAV; the driver will
need to take care of using it during transmit hangs and beacon misses
to see if it's due to a trash looking NAV.

show more ...

[ath] [ath_hal] Propagate the HAL_RESET_TYPE through to the chip reset; set it during ath_reset()

Although I added the reset type field to ath_hal_reset() years ago,
I never finished adding it both

[ath] [ath_hal] Propagate the HAL_RESET_TYPE through to the chip reset; set it during ath_reset()

Although I added the reset type field to ath_hal_reset() years ago,
I never finished adding it both throughout the HALs and in if_ath.c.

This will eventually deprecate the ath_hal force_full_reset option
because it can be requested at the driver layer.

So:

* Teach ar5416ChipReset() and ar9300_chip_reset() about the HAL type
* Use it in ar5416Reset() and ar9300_reset() when doing a full chip reset
* Extend ath_reset() to include the HAL_RESET_TYPE parameter added in the above functions
* Use HAL_RESET_NORMAL in most calls to ath_reset()
* .. but use HAL_RESET_BBPANIC for the BB panics, and HAL_RESET_FORCE_COLD during fatal, beacon miss and other hardware related hangs.

This should be a glorified no-op outside of actual hardware issues.
I've tested things with ath_hal force_full_reset set to 1 for years now,
so I know that feature and a full reset works (albeit much slower than
a warm reset!) and it does unwedge hardware.

The eventual aim is to use this for all the places where the driver
detects a potential hang as well as if long calibration - ie, noise floor
calibration - fails to complete. That's one of the big hardware related
things that causes station mode operation to hang without easy recovery.

Differential Revision: https://reviews.freebsd.org/D24981

show more ...

MFHead @347527

Sponsored by: The FreeBSD Foundation

[ath] [ath_hal] [ath_hal_9300] Extend the start PCU receive to handle resetting ANI.

One of the fun issues with scanning has been how the existing
ANI values were programmed into the hardware when c

[ath] [ath_hal] [ath_hal_9300] Extend the start PCU receive to handle resetting ANI.

One of the fun issues with scanning has been how the existing
ANI values were programmed into the hardware when channels were
changed. If you're on a really crappy channel and ANI has made
you deaf then when you scan you continue to be deaf on all channels.

This code passes in a flag to startpcureceive which in AR5416 and later
is also used to enable ANI. This allows it to know if it's a normal
operation or a scan operation.

This fixes my situation at home where a temporary spot of a device
going deaf due to interference starts scanning and .. can't hear
anything until I restart.

Now, this isn't the full fix - ideally:

(a) all the ANI config and per-channel information would be migrated
to the shared HAL stuff and enabled for all of the NICs;
(b) when a station reassociates and some other error conditions
(like missed beacons, NF calibration failures, etc) a knob
to reset ANI parameters would likely help recovery.

But hey, I'm committing bits of code again! woo!

Tested:

* AR9344 (2G), STA operation

show more ...

[ath_hal] Return failure if noise floor calibration fails.

If we fail noise floor calibration then we may end up with a deaf NIC
which we can't recover without a full chip reset.

Earlier chips seem

[ath_hal] Return failure if noise floor calibration fails.

If we fail noise floor calibration then we may end up with a deaf NIC
which we can't recover without a full chip reset.

Earlier chips seem to get less stuck in this condition versus AR9280/later
and AR9300/later, but whilst here just fix up the AR5212 era chips to also
return NF calibration failures.

This HAL routine would only return failure if the channel was not configured.

This is a no-op until the driver side code for doing resets and the HAL
code for being told about the reset type (and then handling it!) is
implemented.

Tested:

* AR9280, STA mode
* AR2425, STA mode
* AR9380, STA mode

show more ...

Merge ^/head r313055 through r313300.

MFhead@r313243

[ath_hal] [ar9300] link in the CAC enable/diable methods and expose it via the HAL.

[ath_hal] [ar9300] initial radar decode for AR9380 and later chips.

[ath_hal] [ar9300] initial radar detection glue.

* flesh out a "get default DFS parameters" routine
* remove the stub that returns NULL
* fix up the enable DFS method to do what FreeBSD does - speci

[ath_hal] [ar9300] initial radar detection glue.

* flesh out a "get default DFS parameters" routine
* remove the stub that returns NULL
* fix up the enable DFS method to do what FreeBSD does - specifically, allow pe_enabled
to be set/cleared.

This allows the radar pulse reporting code to function, but it doesn't yet
do anything useful.

show more ...

[ath_hal] initialise ah_beaconInterval when the AP/IBSS/TDMA beacon is setup.

[ath_hal] rename the MCI state info routine.

It's not /really/ "get state".

MFH r289384-r293170

Sponsored by: The FreeBSD Foundation

Catch up with head, mostly to merge r291665 with the changes in this branch.

Add initial ar9300 HAL support for the spectral scan mode.

Catch up with head (r291075).

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 re

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.

show more ...

Merge from head

Sponsored by: Gandi.net

Finish merging from head, messed up in previous attempt

Catch up with head, primarily for the 1.14.4.0 firmware.

Merge ^/head r285924 through r286421.

Add a missing method - ath_hal_settsf64().

This is required for TDMA slave mode.

Catch up with HEAD (r280229-r284686).

Merge sync of head

MFH: r280643-r281852

Sponsored by: The FreeBSD Foundation