src/sys/dev/ath/ath_hal/ar5210, branch main

ath_hal: Fix a couple of type mismatches in function prototypes

2023-11-15T02:36:32+00:00

Reported by:	GCC 13 via -Wenum-int-mismatch
Reviewed by:	imp, emaste
Differential Revision:	https://reviews.freebsd.org/D42584

sys: Remove $FreeBSD$: two-line .h pattern

2023-08-16T17:54:11+00:00

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

[ath_hal] Add get/set NAV functions

2021-04-19T05:52:31+00:00

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.

ath: clean up empty lines in .c and .h files

2020-09-01T21:41:07+00:00

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

2019-04-21T02:36:01+00:00

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

SPDX: license IDs for some ISC-related files.

2017-12-08T15:57:29+00:00

[ath_hal] implement NULL methods for ah_setQuiet for AR5210, AR5211.

2017-02-09T23:20:55+00:00

Tested:

* "crap, I didn't bring my cardbus collection and T400 with me" compile
  tested.

[ath_hal] retire a "long RX desc" flag, store/use the TX/RX timestamp length.

2016-07-08T21:34:39+00:00

* the code already stored the length of the RX desc, which I never used.
  So, use that and retire the new flag I introduced a while ago.
* Introduce a TX timestamp length field and capability.

ath(4): begin fleshing out a "reset type" extension to force cold/warn resets.

2015-11-09T15:59:42+00:00

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.

Add initial support for the AR9485 CUS198 / CUS230 variants.

2014-09-30T03:19:29+00:00

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