History log of /freebsd-current/sys/contrib/dev/ath/ath_hal/ar9300/ar9300.h
Revision Date Author Comments
# c1ebd4c9 07-Dec-2022 John Baldwin <jhb@FreeBSD.org>

ath: Fix mismatches in array bounds.

Reported by: GCC -Warray-parameter
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D37542


# 8c01c3dc 25-May-2020 Adrian Chadd <adrian@FreeBSD.org>

[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


# 41137b06 11-May-2020 Adrian Chadd <adrian@FreeBSD.org>

[ath_hal] [ath_hal_ar9300] Fix endian macros to work in and out of kernel tree.

Yes, people shouldn't use bitfields in C for structure parsing.
If someone ever wants a cleanup task then it'd be great to remove them
from this vendor code and other places in the ar9285/ar9287 HALs.

Alas, here we are.

AH_BYTE_ORDER wasn't defined and neither were the two values it could be.
So when compiling ath_ee_print_9300 it'd default to the big endian struct
layout and get a WHOLE lot of stuff wrong.

So:

* move AH_BYTE_ORDER into ath_hal/ah.h where it can be used by everyone.
* ensure that AH_BYTE_ORDER is actually defined before using it!

This should work on both big and little endian platforms.


# a861b06b 24-May-2018 Adrian Chadd <adrian@FreeBSD.org>

[ath_hal] migrate the shared HAL_RESET_* pieces out into ath_hal.

I'm in the process of reworking how the reset path works with an eye
to better recovery when the chips hang and/or go RF/PHY deaf.
This is the first step in a lot of unification and API changes.


# 66c73f1d 02-Feb-2017 Adrian Chadd <adrian@FreeBSD.org>

[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.


# 78b812de 08-Jun-2016 Adrian Chadd <adrian@FreeBSD.org>

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


# 09ff344b 04-Jun-2016 Adrian Chadd <adrian@FreeBSD.org>

[ath_hal] add AR9462 (jupiter) RX gain / XLNA programming.

This seems to make 5G work better.

It doesn't fix powersave handling though, that still sees the PHY get
stuck during initial calibration and everything goes pear shaped.
I'll look into that later.

Tested:

* QCAFN222 NIC, STA mode, 5GHz

Obtained from: Linux ath9k


# d5c3e61a 31-Mar-2015 Adrian Chadd <adrian@FreeBSD.org>

Expose the ANI state / statistics using the public ANI function, rather than
the ar9300_* definitions.

.. which of course don't match, and athstats was reading garbage ANI
data.


# 9778bf37 29-Mar-2015 Adrian Chadd <adrian@FreeBSD.org>

Add initial support for the HAL channel survey support to the AR9300 HAL.

This is used by the 'athsurvey' command to print out channel survey
statistics - % busy times transmit, receive and airtime.

It's as buggy and incomplete as the rest of the HAL survey support -
notably, tying into the ANI code to read channel stats and occasionally
getting garbage counters isn't very nice. It also doesn't (yet!) get
channel survey information during a scan. But it's good enough for
basic air-time debugging, which is why I'm committing it in this state.

Tested:

* AR9380, STA mode


# 3876533b 14-Feb-2015 Adrian Chadd <adrian@FreeBSD.org>

Comment out a double declaration of this particular function name.
It trips up gcc builds.

Pointy-hat-from: jenkins, kib


# 899d1cac 13-Feb-2015 Adrian Chadd <adrian@FreeBSD.org>

Update the AR9300 HAL to the latest public available HAL from QCA.

I've been sitting on this for a year or so now; I've finally
tested it on enough devices to be reasonably sure it won't
cause too much drama. But, if you see issues, please email me.

Tested (all STA mode):

PCIe:

* AR9380
* AR9390
* AR9580
* AR9462
* AR9485

SoC:

* QCA9550
* AR9331
* AR9342


# 77240069 06-Feb-2015 Dimitry Andric <dim@FreeBSD.org>

Fix a number of -Wcast-qual warnings in ath's ar9300_attach.c, by making
the ia_array field of struct ar9300_ini_array const, and removing the
const-dropping casts. No functional change.

Reviewed by: adrian
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D1725


# 9389d5a9 29-Sep-2014 Adrian Chadd <adrian@FreeBSD.org>

Add initial support for the AR9485 CUS198 / CUS230 variants.

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


# e113789b 27-Apr-2013 Adrian Chadd <adrian@FreeBSD.org>

Bring over my FreeBSD modifications for the AR9300 HAL to make it
work in FreeBSD.

This is still heavily a work in progress but I'd rather it start
shipping in -HEAD sooner rather than later.

This doesn't (yet) link it into the build system either for a static
kernel or as a module; that will come later (after many, many make universe
tests.)