ath: Fix typo (triple M)

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/963

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

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

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

SPDX: license IDs for some ISC-related files.

Merge from head@274682

IFC @r272481

Sync to HEAD@r272516.

Reintegrate head@r272414

Sponsored by: The FreeBSD Foundation

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 R

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

show more ...

Merge from head

IFC @ r254014

IFC @253398

Merge fresh head.

Use the TPC bank by default for AR9160.

Tested:

* AR9160, hostap, verified TX power using (2GHz) spectrum analyser

TODO:

* 5GHz verification!

MFC

IFC @ r242684

Sync from head

Oops - missing from the last commit - add ANI immunity levels for AR9160.

Obtained from: Qualcomm Atheros

IFC @230489 (pending review).

IFC @ r226824

Implement the first part of the BB read workaround.

The AR5008/AR9001 series NICs have a bug where BB register reads
will occasionally be corrupted. This could cause issues with things
such as ANI,

Implement the first part of the BB read workaround.

The AR5008/AR9001 series NICs have a bug where BB register reads
will occasionally be corrupted. This could cause issues with things
such as ANI, which adjust operational parameters based on the
BB radio register reads. This was introduced in the AR5008 chip
and fixed with the first released AR9002 series NIC (AR9280v2.)

A followup commit will implement the acutal WAR when reading
BB registers. I'm still not sure how I'll implement it - whether
it should be done in the osdep layer, or whether it should just
live in the AR5416 HAL. Either way, they can use this capability
bit to determine whether to implement the WAR or not.

Thankyou to various sources inside Atheros who have helped me track
down what this particular issue is.

Obtained from: Atheros

show more ...

MFC

Fix a corner case in the HAL debugging changes, where ah was NULL.

Although I tried to fix this earlier by introducing HALDEBUG_G(), it
turns out there seem to be other cases where the pointer value

Fix a corner case in the HAL debugging changes, where ah was NULL.

Although I tried to fix this earlier by introducing HALDEBUG_G(), it
turns out there seem to be other cases where the pointer value is still
NULL.

* Fix DO_HALDEBUG() and the HALDEBUG macro to check whether ah is NULL
before deferencing it
* Remove HALDEBUG_G() as it's no longer needed

This is hopefully a merge candidate for 9.0-RELEASE as enabling
debugging at startup could result in a kernel panic.

show more ...

IFC @ r225592

sys/dev/bvm/bvm_console.c - move up to the new alt-break order.

Integrate FreeBSD/head into projects/zfsd/head as of SVN revision 224870.