wireless-testing
commit 37e5bf6535
Author: Luis R. Rodriguez <lrodriguez@atheros.com>
Date: Sat Jun 12 00:33:40 2010 -0400
ath9k_hw: fix clock rate calculations for ANI
This commit accidentally broke clock rate calculation by doubling the
calculated clock rate
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The 5 GHz CTL indexes were not being read for all hardware
devices due to the masking out through the CTL_MODE_M mask
being one bit too short. Without this the calibrated regulatory
maximum values were not being picked up when devices operate
on 5 GHz in HT40 mode. The final output power used for Atheros
devices is the minimum between the calibrated CTL values and
what CRDA provides.
Cc: stable@kernel.org [2.6.27+]
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The EEPROM is compressed on AR9003, upon decompression
the wrong upper limit was being used for the block which
prevented the 5 GHz CTL indexes from being used, which are
stored towards the end of the EEPROM block. This fix allows
the actual intended regulatory limits to be used on AR9003
hardware.
Cc: stable@kernel.org [2.6.36+]
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This avoids a NULL pointer dereference as reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=625889
When the WARN condition is hit in ieee80211_get_tx_rate, it will return
NULL. So, we need to check the return value and avoid dereferencing it
in that case.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: stable@kernel.org
Acked-by: Bob Copeland <me@bobcopeland.com>
Commit c96c31e499
"(drivers/net/wireless: Use wiphy_<level>)"
inadvertently changed some upper case words to
lower case. Restore the original case.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Atheros PCIe wireless cards handled by ath5k do require L0s disabled.
For distributions shipping with CONFIG_PCIEASPM (this will be enabled
by default in the future in 2.6.36) this will also mean both L1 and L0s
will be disabled when a pre 1.1 PCIe device is detected. We do know L1
works correctly even for all ath5k pre 1.1 PCIe devices though but cannot
currently undue the effect of a blacklist, for details you can read
pcie_aspm_sanity_check() and see how it adjusts the device link
capability.
It may be possible in the future to implement some PCI API to allow
drivers to override blacklists for pre 1.1 PCIe but for now it is
best to accept that both L0s and L1 will be disabled completely for
distributions shipping with CONFIG_PCIEASPM rather than having this
issue present. Motivation for adding this new API will be to help
with power consumption for some of these devices.
Example of issues you'd see:
- On the Acer Aspire One (AOA150, Atheros Communications Inc. AR5001
Wireless Network Adapter [168c:001c] (rev 01)) doesn't work well
with ASPM enabled, the card will eventually stall on heavy traffic
with often 'unsupported jumbo' warnings appearing. Disabling
ASPM L0s in ath5k fixes these problems.
- On the same card you would see a storm of RXORN interrupts
even though medium is idle.
Credit for root causing and fixing the bug goes to Jussi Kivilinna.
Cc: David Quan <David.Quan@atheros.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Tim Gardner <tim.gardner@canonical.com>
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch handles the firmware loading properly
for device ID 7015.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some APs advertise that they may be HT40 capable in the capabilites
but the current operating channel configuration may be only HT20.
This causes disconnection as ath9k_htc sets WLAN_RC_40_FLAG despite
the AP operating in HT20 mode.
Hence set this flag only if the current channel configuration
is HT40 enabled.
Cc: stable@kernel.org
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_rx_skb_preprocess nulls rxs and the mactime is never set again -
mactime is always 0. This causes problems in IBSS mode.
ieee80211_rx_bss_info uses mactime to decide if an IBSS merge is needed.
Without this patch the merge is triggered by each beacon received.
This can be recognized by the "beacon TSF higher than local TSF - IBSS
merge with BSSID" log message accompanying each beacon.
This problem was not completely fixed in commit
a6d2055b02 and is not a stable kernel fix.
It is solely intended for wireless-testing.
Signed-off-by: Jan Friedrich <jft@dev2day.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
I noticed a possible issue in the paused flag management of the
ath_atx_tid data structure. In particular, in a noisy environment and
under heavy load, I observed that the AGGR session establishment could
fail several times consecutively causing values of the paused flag
greater than one for this TID (ath_tx_pause_tid is called more than
once from ath_tx_aggr_start).
Considering that the session for this TID can not be established also
after the mac80211 stack calls the ieee80211_agg_tx_operational() since
the ath_tx_aggr_resume() lowers the paused flag only by one.
This patch also replaces some BUG_ON calls with WARN_ON, as even if
these unlikely conditions happen, it's not fatal enough to justify a
BUG_ON.
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AR9003 was not relying on the CTL indexes from the EEPROM for capping the
max output power. The CTL indexes from the EEPROM provide calibrated
limits for output power for each tested and supported frequency. Without
this the device operates at a power level which only conforms to the
transmit spectrum mask as specified by IEEE Annex I.2.3.
The regulatory limit by CRDA is always used but does not provide
calibrated values for optimal performance, specially on band edges.
Using the calibrated data from the EEPROM ensures the device
operates at optimal output power while still ensuring proper
regulatory compliance. The device uses the minimum of these tree
values, the value from CRDA, the calibrated value from CTL indexex,
and the value to conform to the IEEE transmit spectrum mask.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On AR5008-AR9002, other forms of calibration must not be started while
the noise floor calibration is running, as this can create invalid
readings which were sometimes not even recoverable by any further
calibration attempts.
This patch also ensures that the result of noise floor measurements
are processed faster and also allows the result of the initial
calibration on reset to make it into the NF history buffer
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The noise floor history buffer is currently not kept per channel, which
can lead to problems when changing channels from a clean channel to a
noisy one. Also when switching from HT20 to HT40, the noise floor
history buffer is full of measurements, but none of them contain data
for the extension channel, which it needs quite a bit of time to recover
from.
This patch puts all the per-channel calibration data into a single data
structure, and gives the the driver control over whether that is used
per-channel or even not used for some channels.
For ath9k_htc, I decided to keep this per-channel in order to avoid
creating regressions.
For ath9k, the data is kept only for the operating channel, which saves
some space. ath9k_hw takes care of wiping old data when the operating
channel or its channel flags change.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Previously the software scan callback was used to indicate to the hardware,
when it was safe to calibrate. This didn't really work properly, because it
depends on a specific order of software scan callbacks vs. channel changes.
Also, software scans are not the only thing that triggers off-channel
activity, so it's better to use the newly added indication from mac80211 for
this and not use the software scan callback for anything calibration related.
This fixes at least some of the invalid noise floor readings that I've seen
in AP mode on AR9160
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Writes to the analog shift registers, which are issues by the initval
programming function, require a 100 usec delay (similar to AR9002,
but in a different register range).
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When updating the PAPRD table in hardware, PAPRD itself needs to be
disabled first, otherwise the hardware can throw a data bus error,
which upsets at least some platforms.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The periodic noise floor calibration is broken on this chip family, because
it keeps triggering a software-filtered noise floor calibration, but never
reads the result before uploading the history buffer value to the hardware.
Fix this with a call to ath9k_hw_getnf(), just like on AR9002.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On AR9003 the initial noise floor calibration is currently triggered
at the end of the reset without allowing the hardware to update the
baseband settings. This could potentially make scans in noisy
environments a bit more unreliable, so use the same calibration
sequence that is used on AR9002.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When issuing two consecutive scans you could often end up
getting in the logs:
"ath9k: Two wiphys trying to scan at the same time"
This message is due to a race in mac80211 but addressing
that race requires some more major changes on the driver
and perhaps optimizations on mac80211 like removing the
scan complete callback alltogether. Its too late to address
this this kernel release so supress the complaint and annotate
this needs fixing for later.
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
base index is not used anymore and so remove it.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The user ratekbs of MCS15 ShortGI is incorrect and can not be lesser
than MCS15 rate. This incorrect rate may affect switching to higher
rates as the rate control algorithm always finds MCS15 is better
than MCS15 ShortGI and results in lower throughput. Fix this by
feeding the correct user ratekbs for MCS15 ShortGI rate.
This issue affects 3 stream case very badly as the 3 stream rates are
not used at all once we scale down to MCS15 from 3 stream rates.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds 3 stream rate control support for AR938X family
chipsets which supports 3 streams.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
replace valid and valid_single_stream in rate table with bit masks
and reorganize the code so adding 3x3 rate control would be easier.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The noisefloor array index always corresponds to the rx chain number it
belongs to (with an offset of 3 for the extension chain).
It's much simpler (and actually more correct) to directly use the
chainmask to calculate the bitmask for the noisefloor array, instead of
using these weird chip revision checks and hardcoded mask values.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In the noisefloor array, the extension channel values start at index 3
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the hardware is configured in HT20 mode, noise floor readings for
the extension channel often return invalid values, which keep the
values in the NF history buffer at the hardware-specific maximum limit.
Fix this by discarding the extension channel values when in HT20 mode.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When an aggregation session is being cleaned up, while the tx status
for some frames is being processed, the TID is flushed and its buffers
are sent out.
Unfortunately that left the pending un-acked frames unprocessed, thus
leaking buffers. Fix this by reordering the code so that those frames
are processed first, before the TID is flushed.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sometimes txq state(txq->stopped) can be marked as started but the actual
queue may not be started (in ATH_WIPHY_SCAN state, for example). Fix this.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
snprintf() returns the number of characters that would have been written
(not counting the NUL character). So we can't use it as the limiter to
simple_read_from_buffer() without capping it first at sizeof(buf).
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The snprintf() function returns the number of characters that would have
been written (not counting the NUL character on the end). It could
potentially be larger than the size of the buffer.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
drivers/net/wireless/ath/ath9k/main.c:282:26: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/ath9k/main.c:282:26: expected restricted __le16 [usertype] duration_id
drivers/net/wireless/ath/ath9k/main.c:282:26: got int
Signed-off-by: John W. Linville <linville@tuxdriver.com>
An A-MPDU may contain several subframes each containing its own
CRC for the data. Each subframe also has a respective CRC for the
MPDU length and 4 reserved bits (aka delimeter CRC). AR9003 will
ACK frames that have a valid data CRC but have failed to pass the
CRC for the MPDU length, if and only if the subframe is not the
last subframe in an A-MPDU and if an OFDM phy OFDM reset error has
been caught. Discarding those subframes results in packet loss under
heavy stress conditions, an example being UDP video. Since the
frames are ACK'd by hardware we need to let these frames through
and process them as valid frames.
Cc: Tushit Jain <tushit.jain@atheros.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fixes this sparse complaint:
CHECK drivers/net/wireless/ath/ath9k/htc_drv_main.c
drivers/net/wireless/ath/ath9k/htc_drv_main.c:441:5:
warning: symbol 'ath9k_htc_tx_aggr_oper'
was not declared. Should it be static?
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There were a few places where the sc->rxlink pointer was set to NULL "just in
case". This helps nothing - quite to the contrary it is problematic since it
can create self-linked rx descriptors in the middle of the list of receive
buffers.
Here is an example how this could happen (thanks Bob!):
cpu 0: cpu 1:
ath5k_rx_stop
ath5k_tasklet_rx
sc->rxlink = NULL; /* just in case */
// following doesn't link used
// buffer to prev.
ath5k_rxbuf_setup()
In the case of ath5k_rx_stop() and ath5k_stop_locked() buffers/descriptors are
not changed so rxlink should not be changed as well.
In ath5k_intr() we seem to try to work around a hardware bug, as the comment
(which is copied 1:1 from the HAL) suggests. I don't see how this could help.
Also the HAL does not set rxlink in this case (So where does this code come
from? It has been there since the first import of ath5k). Changed to just
increment a statistics counter.
After this patch rxlink is only set to NULL before we initialize rx descriptors
and updated when the descriptors are linked together.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on a patch from Bruno Randolf, attempting useful
work while we are resetting the chip just leads to interface
lockups and bad descriptor data, and possibly DMAing to
freed buffers. Let's suspend all tasklets while
reprogramming the registers in the card to avoid such
problems.
In the future we can convert the tasklets to threaded
interrupt handlers to simplify things.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We currently trigger a reset via a tasklet when certain error
conditions are detected so that the card will (eventually)
restart. Unfortunately this makes locking complicated since
reset can also be called in process context (e.g. for channel
change). Currently nothing protects against concurrent resets,
which can be the source of corruption bugs.
Reset takes too long to spinlock the whole thing, so this
patch moves deferred resets into the mac80211 workqueue to
enable use of sc->lock mutex.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
According to documentation, The following chip revisions were never sold:
- AR9280 v1.0
- AR9285 v1.0
- AR9285 v1.1
- AR9287 v1.0
Removing initvals specific to these chip revisions saves around 30k in
binary size (tested on MIPS).
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The patch 'ath9k: fix a buffer leak in A-MPDU completion' addressed the
issue of running out of buffers/descriptors in the tx path if a STA is
deleted while tx status feedback is still pending.
The remaining issue is that the skbs of the buffers are not reclaimed,
leaving a memory leak.
This patch fixes this issue by running the buffers through
ath_tx_complete_buf(), ensuring that the pending frames counter is also
updated.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
num_sec_wiphy means max secondary wifis that the driver can accomudate.
So cancelling wiphy work should be based on the presence of
secondary wifis.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove tMinCalPower from ath9k_hw_set_def_power_cal_table(), as it's
never used. Remove corresponding arguments of the functions calculating
that value.
Original patch by Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
LED should be ON when the radio is put into FULL SLEEP mode during the idle
unassociated state.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AR5008+ and AR9003 currently use two separate implementations of the
ath9k_hw_loadnf function. There are three main differences:
- PHY registers for AR9003 are different
- AR9003 always uses 3 chains, earlier versions are more selective
- The AR9003 variant contains a fix for NF load timeouts
This patch merges the two implementations into one, storing the
register array in the ath_hw struct. The fix for NF load timeouts is
not just relevant for AR9003, but also important for earlier hardware,
so it's better to just keep one common implementation.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Occasionally the hardware can send out tx status information with the wrong
TID. In that case, the BA status cannot be trusted and the aggregate
must be retransmitted.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
