For now, the diversity settings are controlled by 'txantenna',
-not- rxantenna. This is because the earlier chipsets had
controllable TX diversity; the RX antenna setting twiddles
the default antenna register. I'll try sort that stuff out at
some point.
Call the antenna switch function from the board setup function
so scans, channel changes, mode changes, etc don't set the
diversity back to a default state too far from what's intended.
Things to todo:
* Squirrel away the last antenna diversity/combining parameters
and restore them during board setup if HAL_ANT_VARIABLE is
defined. That way scans, etc don't reset the diversity settings.
* Add some more public facing statistics, rather than what's
simply logged under HAL_DEBUG_DIVERSITY.
For now, the fixed antenna settings behave better than variable
settings for me. I have some further fiddling to do..
Obtained from: Atheros
keep constant ISN growth rate, do the same directly inside tcp_new_isn(),
taking into account how much time (ticks) passed since the last call.
On my test systems this decreases idle interrupt rate from 140Hz to 70Hz.
The macro which I incorrectly copied into ah_internal.h assumed
that it'd be called with an AR_SREV_MERLIN_20() check to ensure
it was only enabled for Merlin (AR9280) silicon revision 2.0 or
later.
Trouble is, the 5GHz fast clock EEPROM flag is only valid for
EEPROM revision 16 or greater; it's assumed to be enabled
by default for Merlin rev >= 2.0. This meant it'd be incorrectly
set for AR5416 and AR9160 in 5GHz mode.
This would have affected non-default clock timings such as SIFS,
ACK and slot time. The incorrect slot time was very likely wrong
for 5ghz mode.
* Modify AR_SREV_MERLIN_20() to match the Atheros/Linux ath9k behaviour -
its supposed to match Merlin 2.0 and later Merlin chips.
AR_SREV_MERLIN_20_OR_LATER() matches AR9280 2.0 and later chips
(AR9285, AR9287, etc.)
- instead of calling iwn_plcp_signal() for every frame, map the expected
value directly within wn->ridx
- concat plcp, rflags and xrflags, there is no clean byte boundary within
the flags, for example the antenna setting uses bit 6, 7 and 8
- there is still need for a custom rate to plcp mapping, as those expected
by the hardware are not conform to the std
On legacy channels every once in a while the firmware throws a SYSASSERT
on line 208. On HT channels though this does always happen and I'm not
aware of any workaround currently.
was not updated to pass CRD_F_KEY_EXPLICIT flag to opencrypto. This resulted in
always using first key.
We need to support providers created with this bug, so set special
G_ELI_FLAG_FIRST_KEY flag for GELI provider in integrity mode with version
smaller than 6 and pass the CRD_F_KEY_EXPLICIT flag to opencrypto only if
G_ELI_FLAG_FIRST_KEY doesn't exist.
Reported by: Anton Yuzhaninov <citrin@citrin.ru>
MFC after: 1 week
for the given channel is available.
It isn't used yet; ar5416GetWirelessModes() needs to be taught
about this rather than assuming HT20/HT40 is available.
This seems to make the AR9160 behave better during heavy scanning,
where before it'd hang and require a hard reset to recover.
Obtained From: Linux ath9k, Atheros
modifying AR_DIAG_SW.
There's a hardware workaround which sets disabling some errors
early at startup and clears said bits before the PCU begins
receiving - it does this to avoid RX descriptor status errors.
It's possible these bits aren't being completely properly twiddled
in all instances; but in particular if the diag_reg HAL variable
is set it won't be setting these bits correctly. I'll review this
at some point.
* Disable multicast search on mac address and key id - the driver
doesn't use it at the moment and thus adhoc may be broken for
merlin and later.
* Change this to be for Merlin 1.0 (which from what I understand
wasn't ever publicly released) to be more correct.
Apparently all three RX chains need to be enabled before initial calibration
is done, even if only two are configured.
Reorder the alt chain swap bit to match what the Atheros HAL is doing.
Obtained From: ath9k, Atheros
* Shuffle some of the capability numbers around to match the
Atheros HAL capability IDs, just for consistency.
* Add some new capabilities to FreeBSD from the Atheros
HAL which will be be shortly used when new chipsets are added
(HAL SGI-20 support is for Kiwi/AR9287 support); for
TX aggregation (MBSSID aggregate support, WDS aggregation
support); CST/GTT support for carrier sense/TX timeout.
channel when the channel is HT/40.
The new ANI code (primarily for the AR9300/AR9400) in ath9k sets this
register but the ANI code for the previous 11n chips didn't set this.
Unlike ath9k, only set this for HT/40 channels.
Obtained From: ath9k
