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

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

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

[ath_hal] Return failure if noise floor calibration fails.

If we fail noise floor calibration then we may end up with a deaf NIC
which we can't recover without a full chip reset.

Earlier chips seem

[ath_hal] Return failure if noise floor calibration fails.

If we fail noise floor calibration then we may end up with a deaf NIC
which we can't recover without a full chip reset.

Earlier chips seem to get less stuck in this condition versus AR9280/later
and AR9300/later, but whilst here just fix up the AR5212 era chips to also
return NF calibration failures.

This HAL routine would only return failure if the channel was not configured.

This is a no-op until the driver side code for doing resets and the HAL
code for being told about the reset type (and then handling it!) is
implemented.

Tested:

* AR9280, STA mode
* AR2425, STA mode
* AR9380, STA mode

show more ...

SPDX: license IDs for some ISC-related files.

dev/ath: minor spelling fixes in comments.

No functional change.

Reviewed by: adrian

Oops; correctly reload the CCA registers with the uncapped value
in prep for the next NF calibration pass.

Totally missing braces. Damn you C.

Submitted by: Sascha Wildner <swildner@dragonflybsd.o

Oops; correctly reload the CCA registers with the uncapped value
in prep for the next NF calibration pass.

Totally missing braces. Damn you C.

Submitted by: Sascha Wildner <swildner@dragonflybsd.org>
MFC after: 1 week

show more ...

Bump this up to where it used to be.

I need to investigate this a little closer, but it seems that in noisy
environments the NF load takes longer than 5 * DELAY(10) and this is
messing up future NF

Bump this up to where it used to be.

I need to investigate this a little closer, but it seems that in noisy
environments the NF load takes longer than 5 * DELAY(10) and this is
messing up future NF calibrations. (The background: NF calibrations
begin at the value programmed in after the load has completed, so
if this is never loaded in, the NF calibrations only ever start at
the currently calibrated NF value, rather than starting at something
high (say -50.)

More investigation about the effect on 11n RX and calibration results
are needed.

Sponsored by: Hobnob, Inc.

show more ...

Reduce the NF wait timeout. When doing heavy 11n RX loads, this can actually
interfere with traffic, as the NF load can take quite a while and poking the
AGC every 10uS is just a bit silly.

Instead,

Reduce the NF wait timeout. When doing heavy 11n RX loads, this can actually
interfere with traffic, as the NF load can take quite a while and poking the
AGC every 10uS is just a bit silly.

Instead, just leave the baseband NF calibration where it is and just read it
back next time a longcal interval happens.

show more ...

Fix 5ghz calibration logic when using AR9280 w/ fast clock.

When the fast clock (44mhz) is enabled for 5ghz HT20, the
dual ADCs aren't enabled. Trying to do the ADC calibrations
here would result in

Fix 5ghz calibration logic when using AR9280 w/ fast clock.

When the fast clock (44mhz) is enabled for 5ghz HT20, the
dual ADCs aren't enabled. Trying to do the ADC calibrations
here would result in calibration never completing; this
resulted in IQ calibration never running and thus performance
issues in 11a/11n HT20 mode.

Leave it enabled for non-fastclock (40mhz) 11a mode and
HT40 modes.

This has been fixed in discussion with Felix Fietkau (nbd)
and discussions with the Atheros baseband team.

Linux ath9k now has a similar fix.

Approved by: re (kib)

show more ...

I noticed that the Merlin NICs I had (AR9220, AR9280) never completed
the ADC calibrations if the NIC is in 5ghz 11a or 5ghz HT/20 modes.
I've been told that the dual-ADC is only engaged in turbo/40m

I noticed that the Merlin NICs I had (AR9220, AR9280) never completed
the ADC calibrations if the NIC is in 5ghz 11a or 5ghz HT/20 modes.
I've been told that the dual-ADC is only engaged in turbo/40mhz modes.

Since Sowl (AR9160) seems to return valid-looking calibration data
in 5ghz 20MHz modes, I'm only disabling it for Merlin for now.
It may turn out I can disable it for all chipsets and only enable
it for 40MHz modes.

Approved by: re (kib)

show more ...

Fix the AR9280 initial AGC calibration code.

It looks like this was mixed up with the AR9285 calibration code.
This code is now more in line with what Linux ath9k and Atheros
reference drivers do.

Fix the AR9280 initial AGC calibration code.

It looks like this was mixed up with the AR9285 calibration code.
This code is now more in line with what Linux ath9k and Atheros
reference drivers do.

Obtained from: Atheros
Approved by: re (kib)

show more ...

Make sure only two chains are calibrated for the AR9287.

Fix NF calibration breakage introduced by me in a past commit.

Since the returned NF will be -ve, checking for <= 0 is not good
enough. For now, check whether it equals 0 or -1; a future commit
will

Fix NF calibration breakage introduced by me in a past commit.

Since the returned NF will be -ve, checking for <= 0 is not good
enough. For now, check whether it equals 0 or -1; a future commit
will tidy this mess up and have it return HAL_BOOL instead.

show more ...

Even though initial calibrations aren't done (yet), add this so we're
consistent with the Atheros HAL.

Only do open loop power control and temperature compensation
for the AR9280 based NICs if it's actually enabled.

Some of the OLC code was erroneously called during setup
and calibration. This may ha

Only do open loop power control and temperature compensation
for the AR9280 based NICs if it's actually enabled.

Some of the OLC code was erroneously called during setup
and calibration. This may have caused some incorrect behaviour.

show more ...

Make the NF calibration logic (hopefully!) more resistive to noisy
environments.

In setups where NF calibration can take a while, don't load the CCA
and kick off a new NF calibration if the previous

Make the NF calibration logic (hopefully!) more resistive to noisy
environments.

In setups where NF calibration can take a while, don't load the CCA
and kick off a new NF calibration if the previous one hasn't yet
completed. This shouldn't happen unless the environment is noisy but
those exist (hi phk!).

Here, if the previous NF hasn't completed when ar5416LoadNf() is run
(which reads the NF), it skips updating the history buffer, loading
the NF CCA array and kicking off the next NF cal. It's hoped it'll
occur in the next long calibration interval.

Obtained from: Atheros, ath9k, my local HAL

show more ...

Always log if the NF CCA load fails; so users with debugging enabled
can see they're likely in a very noisy environment.

Remove unused variable

Remove the initial NF completion check.

This is taking quite a while for some people in some situations
(eg AR5418 in phk's Abusive Radio Environment).

Instead, the rest of the calibration related

Remove the initial NF completion check.

This is taking quite a while for some people in some situations
(eg AR5418 in phk's Abusive Radio Environment).

Instead, the rest of the calibration related code should
ensure that a NF calibration has occured before reading NF
values and kicking off another NF calibration.

The channel should also likely be marked as "noisy" (CWINT)
if the NF calibration takes too long.

show more ...

Remove a now unneeded comment..

Don't perform NF calibration for radio chains which aren't in use:

Quoting the ath9k commit message:

At present the noise floor calibration is processed in supported
control and extension chains ra

Don't perform NF calibration for radio chains which aren't in use:

Quoting the ath9k commit message:

At present the noise floor calibration is processed in supported
control and extension chains rather than required chains.
Unnccesarily doing nfcal in all supported chains leads to
invalid nf readings on extn chains and these invalid values
got updated into history buffer. While loading those values
from history buffer is moving the chip to deaf state.

This issue was observed in AR9002/AR9003 chips while doing
associate/dissociate in HT40 mode and interface up/down
in iterative manner. After some iterations, the chip was moved
to deaf state. Somehow the pci devices are recovered by poll work
after chip reset. Raading the nf values in all supported extension chains
when the hw is not yet configured in HT40 mode results invalid values.

Reference: https://patchwork.kernel.org/patch/753862/

Obtained from: Linux ath9k

show more ...

Export the per-chain ctl/ext noise floor values, raw and uncut, to the
upper-level HAL.

Right now the per-chain noise floor values aren't used anywhere in
the upper-level HAL, so the driver currentl

Export the per-chain ctl/ext noise floor values, raw and uncut, to the
upper-level HAL.

Right now the per-chain noise floor values aren't used anywhere in
the upper-level HAL, so the driver currently has no real reference
to compare the per-chain RSSI values to.

This is needed before per-chain RSSI values (for ctl and ext radios)
are can be thrown upstairs to the net80211 code.

show more ...

I broke periodic adc calibrations - so restore them to working order.

Disable a check I added a while ago to ensure the initial NF cal completed.

Give it a good go (32 attempts) and then print out a warning that's
going to occur whether HAL debugging is enabled or not

Disable a check I added a while ago to ensure the initial NF cal completed.

Give it a good go (32 attempts) and then print out a warning that's
going to occur whether HAL debugging is enabled or not. Then don't
abort the radio setup; just continue merrily along.

This should fix the issue that users were having where scanning would
occasionally fail on the active channel, causing traffic to cease
until the radio scanned again.

show more ...

Cave in and disable the ADC DC gain/offset calibrations if they're
not needed.

These calibrations are only applicable if the chip operating mode
engages both interleaved RX ADCs (ie, it's compensati

Cave in and disable the ADC DC gain/offset calibrations if they're
not needed.

These calibrations are only applicable if the chip operating mode
engages both interleaved RX ADCs (ie, it's compensating for the
differences in DC gain and DC offset -between- the two ADCs.)
Otherwise the chip reads values of 0x0 for the secondary ADC
(as I guess it's not enabled here) and thus writes potentially
bogus info into the chip.

I've tested this on the AR9160 and AR9280; both behave themselves
in 11g mode with these calibrations disabled.

show more ...