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

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

SPDX: license IDs for some ISC-related files.

MFC @ r266724

An SVM update will follow this.

IFC @266473

Merge head

Do a read-after-write to ensure the interrupt register update is flushed
to the hardware.

The QCA HAL has a comment noting that if this isn't done, modifications
to AR_IMR_S2 before AR_IMR is flushe

Do a read-after-write to ensure the interrupt register update is flushed
to the hardware.

The QCA HAL has a comment noting that if this isn't done, modifications
to AR_IMR_S2 before AR_IMR is flushed may produce spurious interrupts.

Obtained from: QCA

show more ...

Merge fresh head.

sync from head

IFC @247348.

If any of the TX queues have underrun reporting enabled, enable
HAL_INT_TXURN in the interrupt mask register.

This should now allow for TXURN interrupts to be posted.

MFC

IFC @ r234692

sys/amd64/include/cpufunc.h
sys/amd64/include/fpu.h
sys/amd64/amd64/fpu.c
sys/amd64/vmm/vmm.c

- Add API to allow vmm FPU state init/save/restore.

FP stuff discussed with: kib

Merge head r233826 through r234091.

Squirrel away the SYNC interrupt in case we're doing interrupt debugging.

Track and optionally log the actual sync interrupt cause.

These are involved in tracking host interface issues (ie, PCI/PCIe/AHB
interface.)

IFC @230489 (pending review).

IFC @ r227804

Pull in the virtio drivers from head.

Fix the KTR option to compile by default - it was referencing
some unmerged interrupt status debugging code from my branch.

* Add ah_intrstate[8] which will have the record of the last
call to ath

Fix the KTR option to compile by default - it was referencing
some unmerged interrupt status debugging code from my branch.

* Add ah_intrstate[8] which will have the record of the last
call to ath_hal_getintr().
* Wrap the KTR code behind ATH_KTR_INTR_DEBUG.
* Add the HAL interrupt debugging behind AH_INTERRUPT_DEBUGGING.

This is only done for the AR5416 and later NICs but it will be
trivial to add to the earlier NICs if required.

Neither are enabled by default, although to minimise HAL binary
API differences, the ah_intrstate[] array is always compiled into
the ath_hal struct.

show more ...

IFC @ r226824

Various interrupt handling and RX interrupt mitigation fixes.

* The AR_ISR_RAC interrupt processing method has a subtle bug in all
the MAC revisions (including pre-11n NICs) until AR9300v2.
If y

Various interrupt handling and RX interrupt mitigation fixes.

* The AR_ISR_RAC interrupt processing method has a subtle bug in all
the MAC revisions (including pre-11n NICs) until AR9300v2.
If you're unlucky, the clear phase clears an update to one of the
secondary registers, which includes TX status.

This shows up as a "watchdog timeout" if you're doing very low levels
of TX traffic. If you're doing a lot of non-11n TX traffic, you'll
end up receiving a TX interrupt from some later traffic anyway.

But when TX'ing 11n aggregation session traffic (which -HEAD isn't yet
doing), you may find that you're only able to TX one frame (due to
BAW restrictions) and this may end up hitting this race condition.

The only solution is to not use RAC and instead use AR_ISR and the
AR_ISR_Sx registers. The bit in AR_ISR which represents the secondary
registers are not cleared; only the AR_ISR_Sx bits are. This way
any updates which occur between the read and subsequent write will
stay asserted and (correctly) trigger a subsequent interrupt.

I've tested this on the AR5416, AR9160, AR9280. I will soon test
the AR9285 and AR9287.

* The AR_ISR TX and RX bits (and all others!) are set regardless of
whether the contents of the AR_IMR register. So if RX mitigation is
enabled, RXOK is going to be set in AR_ISR and it would normally set
HAL_INT_RX.

Fix the code to not set HAL_INT_RX when RXOK is set and RX mitigation
is compiled in. That way the RX path isn't prematurely called.

I would see:

* An interrupt would come in (eg a beacon, or TX completion) where
RXOK was set but RXINTM/RXMINT wasn't;
* ath_rx_proc() be called - completing RX frames;
* RXINTM/RXMINT would then fire;
* ath_rx_proc() would then be called again but find no frames in the
queue.

This fixes the RX mitigation behaviour to not overly call ath_rx_proc().

* Start to flesh out more correct timer interrupt handling - it isn't
kite/merlin specific. It's actually based on whether autosleep support
is enabled or not.

This is sourced from my 11n TX branch and has been tested for a few weeks.

Finally, the interrupt handling change should likely be implemented
for AR5210, AR5211 and AR5212.

show more ...

Disable TX interrupt mitigation just for the time being.

There are some timing concerns which I've yet to fully map out.
In any case, there's an existing software driven mitigation method
for TX int

Disable TX interrupt mitigation just for the time being.

There are some timing concerns which I've yet to fully map out.
In any case, there's an existing software driven mitigation method
for TX interrupts and when TX'ing 11n frames, the whole frame itself
generates an interrupt rather then the subframes.

show more ...

Introduce AR9130 (HOWL) WMAC support to the FreeBSD HAL.

The AR9130 is an AR9160/AR5416 family WMAC which is glued directly
to the AR913x SoC peripheral bus (APB) rather than via a PCI/PCIe
bridge.

Introduce AR9130 (HOWL) WMAC support to the FreeBSD HAL.

The AR9130 is an AR9160/AR5416 family WMAC which is glued directly
to the AR913x SoC peripheral bus (APB) rather than via a PCI/PCIe
bridge.

The specifics:

* A new build option is required to use the AR9130 - AH_SUPPORT_AR9130.
This is needed due to the different location the RTC registers live
with this chip; hopefully this will be undone in the future.
This does currently mean that enabling this option will break non-AR9130
builds, so don't enable it unless you're specifically building an image
for the AR913x SoC.

* Add the new probe, attach, EEPROM and PLL methods specific to Howl.

* Add a work-around to ah_eeprom_v14.c which disables some of the checks
for endian-ness and magic in the EEPROM image if an eepromdata block
is provided. This'll be fixed at a later stage by porting the ath9k
probe code and making sure it doesn't break in other setups (which
my previous attempt at this did.)

* Sprinkle Howl modifications throughput the interrupt path - it doesn't
implement the SYNC interrupt registers, so ignore those.

* Sprinkle Howl chip powerup/down throughout the reset path; the RTC methods
were

* Sprinkle some other Howl workarounds in the reset path.

* Hard-code an alternative setup for the AR_CFG register for Howl, that
sets up things suitable for Big-Endian MIPS (which is the only platform
this chip is glued to.)

This has been tested on the AR913x based TP-Link WR-1043nd mode, in
legacy, HT/20 and HT/40 modes.

Caveats:

* 2ghz has only been tested. I've not seen any 5ghz radios glued to this
chipset so I can't test it.

* AR5416_INTERRUPT_MITIGATION is not supported on the AR9130. At least,
it isn't implemented in ath9k. Please don't enable this.

* This hasn't been tested in MBSS mode or in RX/TX block-aggregation mode.

show more ...

Fix a corner-case of interrupt handling which resulted in potentially
spurious (and fatal) interrupt errors.

One user reported seeing this:

Apr 22 18:04:24 ceres kernel: ar5416GetPendingInterrupts:

Fix a corner-case of interrupt handling which resulted in potentially
spurious (and fatal) interrupt errors.

One user reported seeing this:

Apr 22 18:04:24 ceres kernel: ar5416GetPendingInterrupts: fatal error,
ISR_RAC 0x0 SYNC_CAUSE 0x2000

SYNC_CAUSE of 0x2000 is AR_INTR_SYNC_LOCAL_TIMEOUT which is a bus timeout;
this shouldn't cause HAL_INT_FATAL to be set.

After checking out ath9k, ath9k_ar9002_hw_get_isr() clears (*masked)
before continuing, regardless of whether any bits in the ISR registers
are set. So if AR_INTR_SYNC_CAUSE is set to something that isn't
treated as fatal, and AR_ISR isn't read or is read and is 0, then
(*masked) wouldn't be cleared. Thus any of the existing bits set
that were passed in would be preserved in the output.

The caller in if_ath - ath_intr() - wasn't setting the masked value
to 0 before calling ath_hal_getisr(), so anything that was present
in that uninitialised variable would be preserved in the case above
of AR_ISR=0, AR_INTR_SYNC_CAUSE != 0; and if the HAL_INT_FATAL bit
was set, a fatal condition would be interpreted and the chip was
reset.

This patch does the following:

* ath_intr() - set masked to 0 before calling ath_hal_getisr();
* ar5416GetPendingInterrupts() - clear (*masked) before processing
continues; so if the interrupt source is AR_INTR_SYNC_CAUSE
and it isn't fatal, the hardware isn't reset via returning
HAL_INT_FATAL.

This doesn't fix any underlying errors which trigger
AR_INTR_SYNC_LOCAL_TIMEOUT - which is a bus timeout of some
sort - so that likely should be further investigated.

show more ...

Rework the Global TX timeout handling to look more like ath9k.

It correctly now sets the AR_IMR BCNMISC register, along with
the GTT register in AR_IMR_S2.

Introduce AH_AR5416_INTERRUPT_MITIGATION which enables interrupt mitigation for
the AR5416 and later. Rename the older HAL option to use this.