The linux ath9k driver and (from what I've been told) the atheros reference
driver does this; it then leaves discarding 11n frames to the 802.11 layer.
Whilst I'm here, merge in a fix from ath9k which maintains a turbo register
setting when enabling the 11n register; and remove an un-needed (duplicate)
flag setting.
The rxmonitor hook is called on each received packet. This can get very,
very busy as the tx/rx/chanbusy registers are thus read each time a packet
is received.
Instead, shuffle out the true per-packet processing which is needed and move
the rest of the ANI processing into a periodic event which runs every 100ms
by default.
sys/dev/ath/ath_hal/ar5416/ is getting very crowded and further
commits will make it even more crowded. Now is a good time to
shuffle these files out before any more extensive work is done
on them.
Create an ar9003 directory whilst I'm here; ar9003 specific
chipset code will eventually live there.
with these ADC DC Gain/Offset calibrations.
The whole idea is to calibrate a pair of ADCs to compensate for any
differences between them.
The AR5416 returns lots of garbage, so there's no need to do the
calibration there.
The AR9160 returns 0 for secondary ADCs when calibrating 2.4ghz 20mhz
modes. It returns valid data for the secondary ADCs when calibrating
2.4ghz HT/40 and any 5ghz mode.
The AR9100 at least doesn't have an external serial EEPROM
attached to the MAC; it instead stores the calibration data
in the normal system flash.
I believe earlier parts can do something similar but I haven't
experienced it first-hand.
This commit introduces an eepromdata pointer into the API but
doesn't at all commit to using it. A future commit will
include the glue needed to allow the AR9100 support code
to use this data pointer as the EEPROM.
the completion schedule from the hardware and returns AH_TRUE if
the hardware supports multi-rate retries (AR5212 and above); and
returns AH_FALSE if the hardware doesn't support multi-rate retries.
The sample rate module directly reads the TX completion descriptor
and extracts the TX schedule information from that. It will be
updated in a future commit to instead use this method to determine
the completion schedule.
If it does, don't then try reprogramming the NF "cap" values (ie
what values are the "maximum" value the NF can be) - instead,
just leave the current CCA value as the NF cap.
This was inspired by some similar work from ath9k. It isn't
a 100% complete solution (as there may be some reason where a
high NF CCA/cap is written, causing the baseband to stop thinking it
is able to transmit, leading to stuck beacon and interface reset)
which I'll investigate and look at fixing in a later commit.
Obtained from: Linux
AR5416 and later chipsets.
ath_hal_calibrateN() calls the HAL calibrateN function with rxchainmask=0x1.
This is not necessarily the case for AR5416 and later chipsets.
o rename the new variables to comply with the naming scheme
o move the new variables to an AR5212 specific struct
o use ahp when available
o revert to previous ts_flags check
available today.
This card is a low power 802.11bgn that only does 11n rates up to MCS 7
(that's 65 Mbps in 20Mhz mode and 135 in 40Mhz mode).
802.11n is not yet supported, but will be in the future.
The driver still has a problem regarding to the setting of txpower on
the card, so don't expect good performance yet. After fixing this
problem, an MFC is possible.
Special thanks to iXsystems and S Smirnov <tonve at yandex.ru> for help
with the purchase of a netbook with this card.
Sponsored by: iXsystems, Inc.
inbound data waiting on a filedescriptor, such as a pipe or a socket,
for instance by using select(2), poll(2), kqueue(2), ioctl(FIONREAD)
etc.
But we have no way of finding out if written data have yet to be
disposed of, for instance, transmitted (and ack'ed!) to some remote
host, or read by the applicantion at the far end of the pipe.
The closest we get, is calling shutdown(2) on a TCP socket in
non-blocking mode, but this has the undesirable sideeffect of
preventing future communication.
Add a complement to FIONREAD, called FIONWRITE, which returns the
number of bytes not yet properly disposed of. Implement it for
all sockets.
Background:
A HTTP server will want to time out connections, if no new request
arrives within a certain period after the last transmitted response
has actually been sent (and ack'ed).
For a busy HTTP server, this timeout can be subsecond duration.
In order to signal to a load-balancer that the connection is truly
dead, TCP_RST will be the preferred method, as this avoids the need
for a RTT delay for FIN handshaking, with a client which, surprisingly
often, no longer at the remote IP number.
If a slow, distant client is being served a response which is big
enough to fill the window, but small enough to fit in the socket
buffer, the write(2) call will return immediately.
If the session timeout is armed at that time, all bytes in the
response may not have been transmitted by the time it fires.
FIONWRITE allows the timeout to check that no data is outstanding
on the connection, before it TCP_RST's it.
Input & Idea from: rwatson
Approved by: re (kib)
o add HAL_CAP_BSSIDMATCH to identify parts that have the support for
disabling bssid match
o honor capability for set/get rx filter
o use HAL_CAP_BSSIDMATCH in driver to decide whether to use the bssid
match disable or fall back to promisc mode
Reviewed by: rpaulo
Approved by: re (rwatson)
