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
The checks should function as follows:
* AR_SREV_<silicon> : check macVersion matches that version id
* AR_SREV_<silicon>_<revision> : check macVersion and macRevision match
the version / revision respectively
* AR_SREV_<silicon>_<revision>_OR_LATER: check that
+ if the chip silicon version == macVersion, enforce revision >= macRevision
+ if the chip silicon version > macVersion, allow it.
For example, AR_SREV_MERLIN() only matches AR9280 (any revision),
AR_SREV_MERLIN_10() would only match AR9280 version 1.0, but
AR_SREV_MERLIN_20_OR_LATER() matches AR9280 version >= 2.0 _AND_
any subsequent MAC (So AR9285, AR9287, etc.)
The specific fixes which may impact users:
* if there is Merlin hardware > revision 2.0, it'll now be correctly
matched by AR_SREV_MERLIN_20_OR_LATER() - the older code simply
would match on either Merlin 2.0 or a subsequent MAC (AR9285, AR9287, etc.)
* Kite version 1.1/1.2 should now correctly match. As these macros
are used in the AR9285 reset/attach path, and it's assumed that the
hardware is kite anyway, the behaviour shouldn't change. It'll only
change if these macros are used in other codepaths shared with
older silicon.
Obtained from: Linux ath9k, Atheros
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.
Writing the TX power registers is the same between all of these chips
and later NICs (AR9287, AR9271 USB, etc.) so this will reduce code
duplication when those NICs are added to the HAL.
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.
It's also marked inactive by the initvals, and enabled after
the baseband/PLL has been configured, but before the RF
registers have been programmed.
The origin and reason for this particular change is currently unknown.
Obtained from: Linux ath9k
Antenna diversity on the >= AR5416 is implemented differently than the
AR5212 and previous chips. So for now, and not to confuse things, just
disable it for now.
* add a new method, specifically for doing per-RX packet
antenna diversity
* set that HAL method only if it's Kite and a Kite chip that
does diversity.
* add a diversity flag to the HAL debugging section
* add a check to make sure the kite diversity code doesn't run
on boards that don't require it, as not all Kite chips will
implement it.
* add some debug statements when the diversity code makes
changes to the antenna diversity/combining setup.
Note: this HAL currently only supports the AR9285.
From Linux ath9k:
The problem is that when the attenuation is increased,
the rate will start to drop from MCS7 -> MCS6, and finally
will see MCS1 -> CCK_11Mbps. When the rate is changed b/w
CCK and OFDM, it will use register desired_scale to calculate
how much tx gain need to change.
The output power with the same tx gain for CCK and OFDM modulated
signals are different. This difference is constant for AR9280
but not AR9285/AR9271. It has different PA architecture
a constant. So it should be calibrated against this PA
characteristic.
The driver has to read the calibrated values from EEPROM and set
the tx power registers accordingly.
ctl/ext noise floor values.
This routine doesn't check to see whether the radio is MIMO
capable - instead, it simply returns either the raw values,
the "nominal" values if the raw values aren't yet available
or are invalid, or '0' values if there's no valid channel/
no valid MIMO values.
Callers are expected to verify the radio is a MIMO radio
(which for now means it's an 11n chipset, there are non-11n
MIMO chipsets out there but I don't think we support them,
at least in MIMO mode) before exporting the MIMO values.
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.
From the ath9k source:
==
11N: we can no longer afford to self link the last descriptor.
MAC acknowledges BA status as long as it copies frames to host
buffer (or rx fifo). This can incorrectly acknowledge packets
to a sender if last desc is self-linked.
==
Since this is useful for pre-AR5416 chips that communicate PHY errors
via error frames rather than by on-chip counters, leave the support
in there, but disable it for AR5416 and later.
Linux ath9k only enables this for AR9280 and later NICs; so
create a capability for it so it isn't enabled for earlier
NICs.
Enabling hardware PS-POLL support will come in a later commit
and will be disabled by default.
