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

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

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

SPDX: license IDs for some ISC-related files.

Merge fresh head.

Sync with HEAD.

IFC @r243836

MFC

MFC @ r241285

.. include ah_desc.h here now.

IFC @ r242684

Sync from head

Merge head r233826 through r239173.

Migrate the ath_hal_filltxdesc() API to take a list of buffer/seglen values.

The existing API only exposes 'seglen' (the current buffer (segment) length)
with the data buffer pointer set in 'ds_data

Migrate the ath_hal_filltxdesc() API to take a list of buffer/seglen values.

The existing API only exposes 'seglen' (the current buffer (segment) length)
with the data buffer pointer set in 'ds_data'. This is fine for the legacy
DMA engine but it won't work for the EDMA engines.

The EDMA engine has a significantly different TX descriptor layout.

* The legacy DMA engine had a ds_data pointer at the same offset in the
descriptor for both TX and RX buffers;
* The EDMA engine has no ds_data for RX - the data is DMAed after the
descriptor;
* The EDMA engine has support for 4 TX buffer/segment pairs in the TX
DMA descriptor;
* The EDMA TX completion is in a different FIFO, and the driver will
'link' the status completion entry to a QCU by a "QCU ID".
I don't know why it's just not filled in by the hardware, alas.

So given that, here are the changes:

* Instead of directly fondling 'ds_data' in ath_desc, change the
ath_hal_filltxdesc() to take an array of buffer pointers as well
as segment len pointers;
* The EDMA TX completion status wants a descriptor and queue id.
This (for now) uses bf_state.bfs_txq and will extract the hardware QCU
ID from that.
* .. and this is ugly and wasteful; it should change to just store
the QCU in the bf_state and save 3/7 bytes in the process.

Now, the weird crap:

* The aggregate TX path was using bf_state->bfs_txq for the TXQ, rather than
taking a function argument. I've tidied that up.
* The multicast queue frames get put on a software TXQ and then that is
appended to the hardware CABQ when appropriate. So for now, make sure
that bf_state->bfs_txq points at the CABQ when adding frames to the
multicast queue.
* .. but the multicast queue TX path for now doesn't use the software
queue and instead
(a) directly sets up the descriptor contents at that point;
(b) the frames on the vap->avp_mcastq are then just appended wholesale
to the CABQ.
So for now, I don't have to worry about making the multicast path
work with aggregation or the per-TID software queue. Phew.

What's left to do:

* I need to modify the 11n ath_hal_chaintxdesc() API to do the same.
I'll do that in a subsequent commit.
* Remove bf_state.bfs_txq entirely and store the QCU as appropriate.
* .. then do the runtime "is this going on the right HWQ?" checks using
that, rather than comparing pointer values.

Tested on:

* AR9280 STA/AP
* AR5416 STA/AP

show more ...

Merge head r233826 through r239010.

Break out the TX descriptor link field into HAL methods.

The DMA FIFO chips (AR93xx and later) differ slightly to th elegacy
chips:

* The RX DMA descriptors don't have a ds_link field;
* The TX DMA

Break out the TX descriptor link field into HAL methods.

The DMA FIFO chips (AR93xx and later) differ slightly to th elegacy
chips:

* The RX DMA descriptors don't have a ds_link field;
* The TX DMA descriptors have a ds_link field however at a different
offset.

This is a reimplementation based on what the reference driver and ath9k
does.

A subsequent commit will enable it in the TX and beacon paths.

Obtained from: Linux ath9k, Qualcomm Atheros

show more ...

IFC @230489 (pending review).

IFC @ r226824

The AR5413 datasheet specifies that AR_TxIntrReq should be set consistently
for all frames, so do so.

MFC

Change the default CABQ time to be 70% of the beacon interval,
rather than the whole beacon interval.

The reference driver and Linux ath9k both choose 80% of the
beacon interval and they do it in th

Change the default CABQ time to be 70% of the beacon interval,
rather than the whole beacon interval.

The reference driver and Linux ath9k both choose 80% of the
beacon interval and they do it in the driver rather than
the HAL (Ath reference) or ath9k_hw (ath9k.)

This quietens stuck beacon conditions on my AR9220/AR9280
based NICs when a lot of burst broadcast/multicast traffic
is going on. It doesn't seem to annoy the earlier MACs as
much as the AR9280 and later one.

Obtained from: Linux ath9k, Atheros

show more ...

Integrate from Head into ZFSD feature branch as of revision r224141.

IFC @ r223696 to pick up dfr's userboot

MFC

Break out most of the HAL related tweaks into a per-HAL instance,
rather than global variables.

This specifically allows for debugging to be enabled per-NIC, rather
than globally.

Since the ath dri

Break out most of the HAL related tweaks into a per-HAL instance,
rather than global variables.

This specifically allows for debugging to be enabled per-NIC, rather
than globally.

Since the ath driver doesn't know about AH_DEBUG, and to keep the ABI
consistent regardless of whether AH_DEBUG is enabled or not, enable the
debug parameter always but only conditionally compile in the debug
methods if needed.

The ALQ support is currently still global pending some brainstorming.

Submitted by: ssgriffonuser@gmail.com
Reviewed by: adrian, bschmidt

show more ...

Merge svn+ssh://svn.freebsd.org/base/head@218816