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

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

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

SPDX: license IDs for some ISC-related files.

Merge ^/head r313301 through r313643.

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

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.

* the code already stored the length of the RX desc, which I never used.
So, use that and retire the new flag I introd

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

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

show more ...

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

MFC @ r266724

An SVM update will follow this.

Merge head

IFC @264767

Merge head up to r263906.

Migrate the chip power mode status to public ath_hal, rather than the
private per-chip HAL.

This allows the ah_osdep.[ch] code to check whether the power state is
valid for doing chip programming.

Migrate the chip power mode status to public ath_hal, rather than the
private per-chip HAL.

This allows the ah_osdep.[ch] code to check whether the power state is
valid for doing chip programming.

It should be a no-op for normal driver work but it does require a
clean kernel/module rebuild, as the size of HAL structures have changed.

Now, this doesn't track whether the hardware is ACTUALLY awake,
as NETWORK_SLEEP wakes the chip up for a short period when traffic
is received. This doesn't actually set the power mode to AWAKE, so
we have to be careful about how we touch things.

But it's enough to start down the path of implementing station mode
chipset power savings, as a large part of the silliness is making
sure the chip is awake during periodic calibration / ANI and
random places where transmit may be occuring. I'd rather not a repeat
of debugging power save on ath9k, where races with calibration
and transmit path stuff took a couple years to shake out.

Tested:

* AR5416, STA mode

show more ...

Merge fresh head.

sync from head

IFC @247348.

Begin adding support to explicitly set the current chainmask.

Right now the only way to set the chainmask is to set the hardware
configured chainmask through capabilities. This is fine for forcing

Begin adding support to explicitly set the current chainmask.

Right now the only way to set the chainmask is to set the hardware
configured chainmask through capabilities. This is fine for forcing
the chainmask to be something other than what the hardware is capable
of (eg to reduce TX/RX to one connected antenna) but it does change what
the HAL hardware chainmask configuration is.

For operational mode changes, it (may?) make sense to separately control
the TX/RX chainmask.

Right now it's done as part of ar5416_reset.c - ar5416UpdateChainMasks()
calculates which TX/RX chainmasks to enable based on the operating mode.
(1 for legacy and whatever is supported for 11n operation.) But doing
this in the HAL is suboptimal - the driver needs to know the currently
configured chainmask in order to correctly enable things for each
TX descriptor. This is currently done by overriding the chainmask
config in the ar5416 TX routines but this has to disappear - the AR9300
HAL support requires the driver to dynamically set the TX chainmask based
on the TX power and TX rate in order to meet mini-PCIe slot power
requirements.

So:

* Introduce a new HAL method to set the operational chainmask variables;
* Introduce null methods for the previous generation chipsets;
* Add new driver state to record the current chainmask separate from
the hardware configured chainmask.

Part #2 of this will involve disabling ar5416UpdateChainMasks() and moving
it into the driver; as well as properly programming the TX chainmask
based on the currently configured HAL chainmask.

Tested:

* AR5416, STA mode - both legacy (11a/11bg) and 11n rates - verified
that AR_SELFGEN_MASK (the chainmask used for self-generated frames like
ACKs and RTSes) is correct, as well as the TX descriptor contents is
correct.

show more ...

MFC @ r241285

IFC @ r242684

Sync from head

Merge head r233826 through r240095.

Add default values for the NumTxMaps capability.