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

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

[ath_hal] Add KeyMiss for AR5212/AR5416 series chips.

This is a flag from the MAC that says the received packet didn't match
a keycache slot. This isn't technically a problem as WEP keys don't
matc

[ath_hal] Add KeyMiss for AR5212/AR5416 series chips.

This is a flag from the MAC that says the received packet didn't match
a keycache slot. This isn't technically a problem as WEP keys don't
match keycache slots (they're "global" keys), but it could be useful
for tracking down CCMP decryption failures.

Right now it's a no-op - it mirrors what the AR9300 HAL does and it
just increments a counter. But, hey, maybe one day I'll use it for
diagnosing keycache/CCMP decrypt issues.

show more ...

MFHead @347527

Sponsored by: The FreeBSD Foundation

[ath] [ath_hal] [ath_hal_9300] Extend the start PCU receive to handle resetting ANI.

One of the fun issues with scanning has been how the existing
ANI values were programmed into the hardware when c

[ath] [ath_hal] [ath_hal_9300] Extend the start PCU receive to handle resetting ANI.

One of the fun issues with scanning has been how the existing
ANI values were programmed into the hardware when channels were
changed. If you're on a really crappy channel and ANI has made
you deaf then when you scan you continue to be deaf on all channels.

This code passes in a flag to startpcureceive which in AR5416 and later
is also used to enable ANI. This allows it to know if it's a normal
operation or a scan operation.

This fixes my situation at home where a temporary spot of a device
going deaf due to interference starts scanning and .. can't hear
anything until I restart.

Now, this isn't the full fix - ideally:

(a) all the ANI config and per-channel information would be migrated
to the shared HAL stuff and enabled for all of the NICs;
(b) when a station reassociates and some other error conditions
(like missed beacons, NF calibration failures, etc) a knob
to reset ANI parameters would likely help recovery.

But hey, I'm committing bits of code again! woo!

Tested:

* AR9344 (2G), STA operation

show more ...

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

Fix the PHY / CRC error bug in the AR5212 HAL, which apparently also pops
up on (at least) the AR5413.

The 30 second summary - if a CRC error frame comes in during PHY error
processing, that CRC bit

Fix the PHY / CRC error bug in the AR5212 HAL, which apparently also pops
up on (at least) the AR5413.

The 30 second summary - if a CRC error frame comes in during PHY error
processing, that CRC bit will be set for all subsequent frames until
a non-CRC error frame is processed.

So to allow for accurate PHY error processing (Radar, and ANI on the AR5212
HAL chips) just tag the frame as being both CRC and PHY - let the driver
decide what to do with it.

PR: kern/169362

show more ...

Merge head r236710 through r238467.

IFC @238412.

IFC @ r238370

Extend the RX HAL API to include the RX queue identifier.

The AR93xx and later chips support two RX FIFO queues - a high and low
priority queue.

For legacy chips, just assume the queues are high pr

Extend the RX HAL API to include the RX queue identifier.

The AR93xx and later chips support two RX FIFO queues - a high and low
priority queue.

For legacy chips, just assume the queues are high priority.

This is inspired by the reference driver but is a reimplementation of
the API and code.

show more ...

Add some more OS_MARK probes to the RX DMA setup/teardown code path.

I'm trying to debug the RX DMA path and help the ath9k guys with
"RX dma abort stuck" issue that both our drivers have.

Make sure that the AR_MISC_MODE value from the initvals are properly respected.

This commit really is "fix the OFDM duration calculation to match reality when
running in 802.11g mode."

The AR5212 i

Make sure that the AR_MISC_MODE value from the initvals are properly respected.

This commit really is "fix the OFDM duration calculation to match reality when
running in 802.11g mode."

The AR5212 init vals set AR_MISC_MODE to 0x0 and all the bits that can be set are
set through code.

The AR5416 and later initvals set AR_MISC_MODE to various other values (with
the AR5212 AR_MISC_MODE options cleared), which include AR_PCU_CCK_SIFS_MODE .
This adds 6uS to SIFS on non-CCK frames when transmitting.

This fixes the issue where _DATA_ 802.11g OFDM frames were being TX'ed with
the ACK duration set to 38uS, not 44uS as on the AR5212 (and other devices.)

The AR5212 TX pathway obeys the software-programmed duration field in the packet,
but the 11n TX pathway overrides that with a hardware-calculated duration. This
was getting it wrong because of the above AR_MISC_MODE setting. I've verified
that 11g data OFDM frames are now being TXed with the correct ACK+SIFS duration
programmed in.

show more ...

Merge from head

- MFC @196061

Fix handling of AR_RX_FILTER_BSSID: write the shadow value for AR_MISC_MODE
so other register writes preserve the setting of AR_MISC_MODE_BSSID_MATCH_FORCE.

Reviewed by: rpaulo
Approved by: re (kib)

- MFC