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

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

SPDX: license IDs for some ISC-related files.

Merge from head

IFC @ r254014

IFC @253398

Merge fresh head.

Fix build break - the SetCapability calls return HAL_BOOL,
not HAL_STATUS.

Extend the TXOP enforce capability to support checking whether it's
supported.

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

Sync with HEAD.

IFC @r243836

Add a new HAL capability - check and enforce whether the NIC supports
enforcing the TXOP and TBTT limits:

* Frames which will overlap with TBTT will not TX;
* Frames which will exceed TXOP will be f

Add a new HAL capability - check and enforce whether the NIC supports
enforcing the TXOP and TBTT limits:

* Frames which will overlap with TBTT will not TX;
* Frames which will exceed TXOP will be filtered.

This is not enabled by default; it's intended to be enabled by the
TDMA code on 802.11n capable chipsets.

show more ...

MFC

MFC @ r241285

Add a comment which covers what's going on with the 64 bit TSF write.

After chatting with the MAC team, the TSF writes (at least on the 11n
MACs, I don't know about pre-11n MACs) are done as 64 bit

Add a comment which covers what's going on with the 64 bit TSF write.

After chatting with the MAC team, the TSF writes (at least on the 11n
MACs, I don't know about pre-11n MACs) are done as 64 bit writes that
can take some time. So, doing a 32 bit TSF write is definitely not
supported. Leave a comment here which explains that.

Whilst here, add a comment which outlines that after a reset or TSF
write, the TSF write may take a while (up to 50uS) to update.
A write or reset shouldn't be done whilst the previous one is in
flight. Also (and this isn't currently done) a read shouldn't
occur until the SLEEP32_TSF_WRITE_STAT is clear. Right now we're
not doing that, mostly because we haven't been doing lots of TSF
resets/writes until recently.

show more ...

Implement a HAL method to set a 64 bit TSF value.

TODO: implement it (and test) for the AR5210/AR5211.

IFC @ r242684

Sync from head

Call the ar5212SetCoverageClass() function for now.

Some of the math is a little wrong thanks to clocks in 11a mode running
at 44MHz when in fast clock mode (rather than 40MHz, which the chips
befor

Call the ar5212SetCoverageClass() function for now.

Some of the math is a little wrong thanks to clocks in 11a mode running
at 44MHz when in fast clock mode (rather than 40MHz, which the chips
before AR9280 ran 11a in). That'll have to be addressed in a future commit.

show more ...

Merge head r236710 through r238467.

IFC @238412.

IFC @ r238370

Migrate the MAC/BB hang structures out from ar5416_misc.h into the HAL.

The ar9300 HAL also uses these types, so it makes no sense to duplicate
them.