The AR_IMR_S2 register sometimes cannot be read correctly. Instead of a
valid value, 0xdeadbeef is returned. The driver has been observed
writing that value back to AR_IMR_S2 after changing a few bits.
Cache the register value in ah->imrs2_reg and always write chached value
to the register.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath5k_hw_register_timeout() was duplicated between phy.c and reset.c.
Since it is too big and too much used to be an inline function, move it
away from the ath5k.h header into reset.c. Remove _ATH5K_RESET and
_ATH5K_PHY defines.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Adjust formatting of the affected lines to satisfy checkpatch.pl.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove all unnecessary function declarations from ath5k.h. Comment out
unused functions. Remove ath5k_hw_get_tsf32(), which is too trivial to
be commented out. Make functions static if suggested by sparse. Make
ath5k_pm_ops static.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Handling HT configuration changes involved setting the channel
with the new HT parameters and then issuing a rate_update()
notification to the driver.
This behavior changed after the off-channel changes. Now, the channel
is not updated with the new HT params in enable_ht() - instead, it
is now done when the scan work terminates. This results in the driver
depending on stale information, defaulting to non-HT mode always.
Fix this by passing the new channel type to the driver.
Cc: stable@kernel.org
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This converts ar9170 to load firmware asynchronously
out of ->probe() and only register with mac80211 when
all firmware has been loaded successfully. If, on the
other hand, any firmware fails to load, it will now
unbind from the device.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
While ath9k does not support RIFS yet, the ability to receive RIFS
frames is currently enabled for most chipsets in the initvals.
This is causing baseband related issues on AR9160 and AR9130 based
chipsets, which can lock up under certain conditions.
This patch fixes these issues by overriding the initvals, effectively
disabling RIFS for all affected chipsets.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This converts ath9k to use the new station
add/remove callbacks instead of using the
old sta_notify callback.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This converts ar9170 to use the new station
add/remove callbacks instead of using the
old sta_notify callback.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In AP mode, ath_beacon_config_ap only restarts the timer if a TSF
restart is requested. Apparently this was added, because this function
unconditionally sets the flag for TSF reset.
The problem with this is, that ath9k_hw_reset() clobbers the timer
registers (specified in the initvals), thus effectively disabling the
SWBA interrupt whenever a card reset without TSF reset is issued
(happens in a few places in the code).
This patch fixes ath_beacon_config_ap to only issue the TSF reset flag
when necessary, but reinitialize the timer unconditionally. Tests show,
that this is enough to keep the SWBA interrupt going after a call to
ath_reset()
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When selecting the tx fallback rate, rc.c used a separate variable
'nrix' for storing the next rate index, however it did not use that as
reference for further rate index lowering. Because of that, it ended up
reusing the same rate for multiple multi-rate retry stages, thus
decreasing delivery probability under changing link conditions.
This patch removes the separate (unnecessary) variable and fixes
fallback the way it was intended to work.
This should result in increased throughput and better link stability.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Instead of hardcoding the lowest rate for Beacon frames, use the rate
index specified in the mac80211 TX info in AP mode.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Adding support for setting the coverage class in some cases broke
association and data transfer, as it overwrote the initial ACK timeout
value from the initvals with a smaller value.
I don't know why the new value works in 5 GHz (matches the initval
there), but not in 2.4 GHz (initvals use 64us here), so until the
problem is fully understood, the value should be increased again.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The hardware needs to know what type of frames are being
sent in order to fill in various fields, for example the
timestamp in probe responses (before this patch, it was
always 0). Set it correctly when initializing the TX
descriptor.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently, PAE frames are not assigned proper sequence numbers.
Since sending PAE frames as part of aggregates breaks
crupto with several APs, they are sent as normal MPDUs.
Fix the seqeuence number issue by updating the frame with the
internal sequence number.
Tested-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a WARN_ON which is triggered
by Poland's country code.
ath: EEPROM regdomain: 0x8268
ath: EEPROM indicates we should expect a country code
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x37
ath: Country alpha2 being used: PL
ath: Regpair used: 0x37
-----------[ cut here ]------------
WARNING: at drivers/net/wireless/ath/regd.c:155 ath_regd_init+0x30b
Pid: 12661, comm: firmware/carl91 2.6.33-rc5-wl #18
Call Trace:
[<>] ? warn_slowpath_common+0x76/0x8c
[<>] ? ar9170_reg_notifier+0x0/0x2d [carl9170usb]
[<>] ? ath_regd_init+0x30b/0x377 [ath]
[<>] ? ar9170_register+0x3b3/0x3ca [carl9170usb]
[...]
---[ end trace ]---
Note: Poland is just an example. But it is very likely
that more country codes are affected.
Cc: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
get_tx_stats() will be removed from mac80211.
Compile-tested only.
Cc: Jiri Slaby <jirislaby@gmail.com>
Cc: Nick Kossifidis <mickflemm@gmail.com>
Cc: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Kalle Valo <kalle.valo@iki.fi>
Acked-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
get_tx_stats() will be removed from mac80211.
Because ar9170 uses ieee80211_tx_queue_stats internally, create a new
identical struct ar9170_tx_queue_stats which the driver can use.
Compile-tested only.
Signed-off-by: Kalle Valo <kalle.valo@iki.fi>
Tested-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If split tkip key is used, ath_delete_key should delete
rx key and rx mic key. This patch fixes the leak of hw
keycache in the case.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The TIM timer interrupt is enabled even before the ACK of nullqos
is received which is unnecessary.
Also clean up the CONF_PS part of config callback properly for
better readability.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
beacons configuration SHOULD be done only if the STA is associated.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some single chip family devices are sold in the market with
802.11n bonded out, these have no hardware capability for
802.11n but ath9k can still support them. These are called
AR2427.
Cc: stable@kernel.org
Reported-by: Rolf Leggewie <bugzilla.kernel.org@rolf.leggewie.biz>
Tested-by: Bernhard Reiter <ockham@raz.or.at>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Calling ath_bus_cleanup() after ieee80211_free_hw() resulted in access
to common->bus_ops, which is already freed as part of the device data.
Remove the cleanup field in struct ath_bus_ops, as it was never used
properly. Remove ath_bus_cleanup(). Merge cleanup functions in place
of the ath_bus_cleanup() calls. Take care not to use any device data
after ieee80211_free_hw().
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Using stack for that causes warnings with CONFIG_FRAME_WARN=1024
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Numeric channel is hard to get, so it won't be printed. Replace Mhz
with MHz on the affected lines and add commas as needed.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
IDLE PS (Full Sleep) doesn't work when ifconfig up
is done during Idle unassociated state.
Fix this by restoring FULL SLEEP in ps_restore if CONF_IDLE
is set.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With following patch, LED should now work with LiteOn AR5BXB63 mini
pci-e cards.
(Broken patch fixed-up by me...let's hope I did it right! -- JWL)
Signed-off-by: Luca Verdesca <magooz@salug.it>
Acked-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k currently forces hw->max_rate_tries to 4 to work around rate
control inefficiencies. This has some negative side effects, such as
rate_control_send_low also using a maximum of 4 tries, which could
negatively affect reliability of unicast management frames.
This patch pushes the retry limit to the rate control instead, and
allows it to use more tries on the last stage to prevent unnecessary
packet loss.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Among other changes, this commit:
commit 06d0f0663e
Author: Sujith <Sujith.Manoharan@atheros.com>
Date: Thu Feb 12 10:06:45 2009 +0530
ath9k: Enable Fractional N mode
changed the hw attach code to fix up initialization values only for
dual band devices, however the commit message did not give a reason as
to why this would be useful or necessary.
According to tests by Jorge Boncompte, this breaks at least some
2GHz-only cards, so the code should be changed back to the
unconditional INI fixup.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Jorge Boncompte <jorge@dti2.net>
Cc: stable@kernel.org
Tested-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As all bt packets are priority traffic during bt scan, wifi
will get disconnected when bt scan lasts for few seconds. Fix
this by allocating 10% of bt period time (4.5ms) to wifi fully.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The beacon sent gating doesn't seem to work with any combination
of flags. Thus, buffered frames tend to stay buffered forever,
using up tx descriptors.
Instead, use the DBA gating and hold transmission of the buffered
frames until 80% of the beacon interval has elapsed using the ready
time. This fixes the following error in AP mode:
ath5k phy0: no further txbuf available, dropping packet
Add a comment to acknowledge that this isn't the best solution.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When using the external sleep clock in AP mode, the
TSF increments too quickly, causing beacon interval
to be much lower than it is supposed to be, resulting
in lots of beacon-not-ready interrupts.
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=14802.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When cleaning up beacon buffers and slots, ath9k currently checks if
sc->ah->opmode is set to a beacon related mode before cleaning up
buffers.
An unfortunate ordering of interface up/down commands can lead to
sc->ah->opmode being set to monitor mode, while there are AP interfaces
present on the same wiphy.
Always cleaning up beacon buffers if present fixes this issue.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Users wishing to tweak tx power want it to happen immediately,
try to respect that. This was tested by Lorenzo by measuring the
received signal strength from an AP with ath9k and the patch.
Changing the tx power on the AP produced these results:
1) iwconfig wlan0 txpower 20 ---> Rx power -37dbm
2) iwconfig wlan0 txpower 15 ---> Rx power -41dbm
3) iwconfig wlan0 txpower 10 ---> Rx power -45dbm
4) iwconfig wlan0 txpower 5 ---> Rx power -51dbm
5) iwconfig wlan0 txpower 0 ---> Rx power -37dbm
The result with 0 is an anomoly and would need to be
addressed through a separate patch.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Tested-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The Tx DMA descriptor has two kinds of flags that select RTS/CTS usage.
The first one (global for the frame) selects whether RTS/CTS or
CTS-to-self should be used, the second one enables RTS/CTS or
CTS-to-self usage for an individual multi-rate-retry entry.
Previously the code preparing the descriptor only enabled the global
flag, if the first MRR series selected the local one.
Fix this by enabling the global flag if any of the MRR entries need it.
With this patch, rate control can properly select the use of RTS/CTS
for all MRR entries except the first one, which is the default behavior.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Previously ath9k left the initialization of slot timing and ACK/CTS
timeout to the mode specific initvals. This does not handle short vs
long slot in 2.4 GHz and uses a rather strange value for the 2.4 GHz
ACK timeout (64 usec).
This patch uses the proper ath9k_hw functions for setting slot time and
timeouts and also implements the switch between short and long slot
time in 2.4 GHz
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The device has to be marked as invalid before
registering the ISR. HW initialization takes place
after the ISR has been registered, and the invalid
flag is eventually cleared in the ->stop() callback.
Reported-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 passes appropriate flags indicating whether
monitor mode is being used. Use this to set the HW opmode.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This file can be used to track frame reception errors.
PHY error counts are also added.
Location: ath9k/phy#/recv
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The TX queues have to be stopped during an
internal reset. Not handling this would result
in packet loss - fix this.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The device initialization and termination functions
were messy and convoluted. Introduce helper functions
to clarify init_softc() and simplify things in general.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
sc_flags has slowly become a kitchen sink over time.
Move powersave related flags to a separate variable.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move initialization/de-initialization related
code to this file.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move all LED/RFKILL/BTCOEX related code
to gpio.c
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The callback sets slot time as specified in IEEE 802.11-2007 section
17.3.8.6 (for 20MHz channels only for now) and raises ACK and CTS
timeouts accordingly. The values are persistent, they are restored after
device reset.
Signed-off-by: Lukas Turek <8an@praha12.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The original code was correct in 802.11a mode only, 802.11b/g uses
different clock rates. The new code uses values taken from FreeBSD HAL
and should be correct for all modes including turbo modes.
The former rate calculation was used by slope coefficient calculation
function ath5k_hw_write_ofdm_timings. However, this function requires
the 802.11a values even in 802.11g mode. Thus the use of
ath5k_hw_htoclock was replaced by hardcoded values. Possibly the slope
coefficient calculation is not related to clock rate at all.
Signed-off-by: Lukas Turek <8an@praha12.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Functions ath5k_hw_get_slot_time and ath5k_hw_set_slot_time were
converting microseconds to clocks only for AR5210, although it's needed
for all supported devices. The conversion was moved outside the
hardware-specific branches.
The original code also limited minimum slot time to 9, while turbo modes
use 6, this was fixed too.
Signed-off-by: Lukas Turek <8an@praha12.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The newer single chip hardware family of chipsets have not been
experiencing issues with power saving set by default with recent
fixes merged (even into stable). The remaining issues are only
reported with AR5416 and since enabling PS by default can increase
power savings considerably best to take advantage of that feature
as this has been tested properly.
For more details on this issue see the bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=14267
We leave AR5416 with PS disabled by default, that seems to require
some more work.
Cc: stable@kernel.org
Cc: Peter Stuge <peter@stuge.se>
Cc: Justin P. Mattock <justinmattock@gmail.com>
Cc: Kristoffer Ericson <kristoffer.ericson@gmail.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use DEFINE_PCI_DEVICE_TABLE() so we get place PCI ids table into correct section
in every case.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 enabled EEPROM
checksum checks to avoid bogus bug reports but failed to address
updating the code to consider devices with custom EEPROM sizes.
Devices with custom sized EEPROMs have the upper limit size stuffed
in the EEPROM. Use this as the upper limit instead of the static
default size. In case of a checksum error also provide back the
max size and whether or not this was the default size or a custom
one. If the EEPROM is busted we add a failsafe check to ensure
we don't loop forever or try to read bogus areas of hardware.
This closes bug 14874
http://bugzilla.kernel.org/show_bug.cgi?id=14874
Cc: stable@kernel.org
Cc: David Quan <david.quan@atheros.com>
Cc: Stephen Beahm <stephenbeahm@comcast.net>
Reported-by: Joshua Covington <joshuacov@googlemail.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The unit of sizeof() is byte instead of bit, so fix it.
The patch can fix debug output of some dma_addr_t variables.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add missing DEBUG_FS dependency for ATH9K_DEBUGFS in ath9k's Kconfig.
Signed-off-by: Dominik D. Geyer <dominik.geyer@gmx.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
All its members (vif, mac_addr, type) are now available
in the vif struct directly, so we can pass that instead
of the conf struct. I generated this patch (except the
mac80211 and header file changes) with this semantic
patch:
@@
identifier conf, fn, hw;
type tp;
@@
tp fn(struct ieee80211_hw *hw,
-struct ieee80211_if_init_conf *conf)
+struct ieee80211_vif *vif)
{
<...
(
-conf->type
+vif->type
|
-conf->mac_addr
+vif->addr
|
-conf->vif
+vif
)
...>
}
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
My previous change added in:
commit 815833e7ec
ath9k: fix tx status reporting
was not checking all possible tx error conditions. This could possibly
lead to throughput issues due to slow rate control adaption or missed
retransmissions of failed A-MPDU frames.
This patch adds a mask for all possible error conditions and uses it
in the xmit ok check.
Cc: stable@kernel.org
Reported-by: Björn Smedman <bjorn.smedman@venatech.se>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AMDPDU actions poke hardware for TX operation, as such
we want to turn hardware on for these actions. AMDPU RX operations
do not require hardware on as nothing is done in hardware for
those actions. Without this we cannot guarantee hardware has
been programmed correctly for each AMPDU TX action.
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When we remove a IBSS/AP/Mesh interface we stop DMA
but to do this we should ensure hardware is on. Awaken
the device prior to these calls. This should ensure
DMA is stopped upon suspend and plain device removal.
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ensure the device is awake prior to trying to tell hardware
to stop it. Impact of not doing this is we can likely leave
the device in an undefined state likely causing issues with
suspend and resume. This patch ensures harware is where it
should be prior to suspend.
Cc: stable@kernel.org
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This removes the remaining users of the rx status
'qual' field and the field itself.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The calibration period is now invoked by triggering a software
interrupt from within the ISR by ath5k_hw_calibration_poll()
instead of via a timer.
However, the calibration interval isn't initialized before
interrupts are enabled, so we can have a situation where an
interrupt occurs before the interval is assigned, so the
interval is actually negative. As a result, the ISR will
arm a software interrupt to schedule the tasklet, and then
rearm it when the SWI is processed, and so on, leading to a
softlockup at modprobe time.
Move the initialization order around so the calibration interval
is set before interrupts are active. Another possible fix
is to schedule the tasklet directly from the poll routine,
but I think there are additional plans for the SWI.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Disable the TX hang monitoring routine when doing a scan.
Monitoring for a hung situation is not really necessary during
a scan run.
Cc: stable@kernel.org
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cancel/restart the ANI timer directly.
With this patch, the ANI lock can be removed.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k currently supports only RX interrupt
mitigation.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a rather embarrassing typo.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch aggregates a bunch of small random changes
that won't fit really anywhere else properly.
1. move tid-locating macro into a separate function.
2. remove redundant NULL check.
3. add modulation mask definition
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The flags in question were once useful for debugging.
Time has passed and now they do nothing more than
duplicating txinfo->flags.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AR9170 has the bad habit of choking when traffic builds up.
Tests have shown that this can partially be attributed to
a huge buildup of backlogged frames.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch removes dead infrastructure which was meant
for an out-of-tree rate control algorithm.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The MIB counters are disabled when doing a chip reset.
Since ANI depends on the MIB registers for its operation, relying
on the contents of said registers during HW reset results in sub-optimal
performance.
Cc: stable@kernel.org
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When TX DMA termination has failed, the HW has to be reset
completely. Doing a fast channel change in this case is insufficient.
Also, change the debug level of a couple of messages to FATAL.
Cc: stable@kernel.org
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The internal, driver-specific maintenance of sequence
numbers is applicable only for HT frames.
Also, remove comments that are not relevant anymore.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
First, we copy/paste the padding stuff from ath9k_tx to ath_tx_cabq since it
needs to same kind of padding, but for internally generated beacons.
Next, software padding done on TX needs to be removed before calling
ieee80211_tx_status. The code was already there in ath_tx_complete but it
was wrong. Fix it by using ath9k_cmn_padpos. This later code has been
tested by sending packets to a monitor interface and reading packets from the
same interface.
Signed-off-by: Benoit PAPILLAULT <benoit.papillault@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Without this we have no gaurantee of the integrity of the
EEPROM and are likely to encounter a lot of bogus bug reports
due to actual issues on the EEPROM. With the EEPROM checksum
check in place we can easily rule those issues out.
If you run patch during a revert *you* have a card with a busted
EEPROM and only older kernel will support that concoction. This
patch is a trade off between not accepitng bogus EEPROMs and
avoiding bogus bug reports allowing developers to focus instead
on real concrete issues.
If stable keeps bogus bug reports because of a possibly busted EEPROM
feel free to apply this there too.
Tested on an AR5414
Cc: stable@kernel.org
Cc: jirislaby@gmail.com
Cc: akpm@linux-foundation.org
Cc: rjw@sisk.pl
Cc: me@bobcopeland.com
Cc: david.quan@atheros.com
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Adds support for the WiFi activity LED on the Dell Vostro A860 laptop.
Signed-off-by: Shahar Or <shahar@shahar-or.co.il>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a bug in ath9k's tx status check, which
caused mac80211 to consider regularly transmitted unicast frames
as un-acked.
When checking the ts_status field for errors, it needs to be masked
with ATH9K_TXERR_FILT, because this field also contains other fields
like ATH9K_TX_ACKED.
Without this patch, AP mode is pretty much unusable, as hostapd
checks the ACK status for the frames that it injects.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
"Definition" is misspelled "defintion" in several comments; this
patch fixes them. No code changes.
Signed-off-by: Adam Buchbinder <adam.buchbinder@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Currently, the 2GHz band is enabled unconditionally, even if the device
does not support it.
Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
fix some typos and punctuation in comments
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In my setups, ath9k's debugfs files are most of the time much more
useful than the messages generated by enabling CONFIG_ATH_DEBUG along
with the right debug flags.
Since CONFIG_ATH_DEBUG comes with a noticeable overhead on embedded
systems, this patch makes it possible to use the debugfs files without
that option.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Update the beacon queue parameters with best effort queue parameters for
IBSS mode. This reduces the number of beacons generated by ath9k and
ensures a fair beacon distribution when there are multiple IBSS stations.
Also CWmin is quadrupled to achieve the expected percentage of
distribution.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Atheros single stream AR9285 and AR9271 have half the PCU TX FIFO
buffer size of that of dual stream devices. Dual stream devices
have a max PCU TX FIFO size of 8 KB while single stream devices
have 4 KB. Single stream devices have an issue though and require
hardware only to use half of the amount of its capable PCU TX FIFO
size, 2 KB and this requires a change in software.
Technically a change would not have been required (except for frame
burst considerations of 128 bytes) if these devices would have been
able to use the full 4 KB of the PCU TX FIFO size but our systems
engineers recommend 2 KB to be used only. We enforce this through
software by reducing the max frame triggger level to 2 KB.
Fixing the max frame trigger level should then have a few benefits:
* The PER will now be adjusted as designed for underruns when the
max trigger level is reached. This should help alleviate the
bus as the rate control algorithm chooses a slower rate which
should ensure frames are transmitted properly under high system
bus load.
* The poll we use on our TX queues should now trigger and work
as designed for single stream devices. The hardware passes
data from each TX queue on the PCU TX FIFO queue respecting each
queue's priority. The new trigger level ensures this seeding of
the PCU TX FIFO queue occurs as designed which could mean avoiding
false resets and actually reseting hw correctly when a TX queue
is indeed stuck.
* Some undocumented / unsupported behaviour could have been triggered
when the max trigger level level was being set to 4 KB on single
stream devices. Its not clear what this issue was to me yet.
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Cc: Bennyam Malavazi <bennyam.malavazi@atheros.com>
Cc: Stephen Chen <stephen.chen@atheros.com>
Cc: Shan Palanisamy <shan.palanisamy@atheros.com>
Cc: Paul Shaw <paul.shaw@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Software padding is done on the TX path and software unpadding is done on the
RX path. This patch corrects the position where the padding occurs. A specific
function computes the pad position and this function is used in the TX and RX
path. This patch has been tested by generating every possible 802.11 frames
with every possible frame_control field and a varying length. This patch is
useful for analyzing non standard 802.11 frames going over the air
Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When mac80211 was telling us to go into Powersave we listened
and immediately turned RX off. This meant hardware would not
see the ACKs from the AP we're associated with and hardware
we'd end up retransmiting the null data frame in a loop
helplessly.
Fix this by keeping track of the transmitted nullfunc frames
and only when we are sure the AP has sent back an ACK do we
go ahead and shut RX off.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Vivek Natarajan <Vivek.Natarajan@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove some fields from struct ath_rate_table that are now unused.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch changes ath9k to pass proper MCS indexes and flags
between the RC and the rest of the driver code.
sc->cur_rate_table remains, as it's used by the RC code internally,
but the rest of the driver code no longer uses it, so a potential
new RC for ath9k would not have to update it.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CC [M] drivers/net/wireless/ath/ath9k/recv.o
drivers/net/wireless/ath/ath9k/recv.c: In function `ath_rx_prepare':
drivers/net/wireless/ath/ath9k/recv.c:208: warning: comparison is always true due to limited range of data type
drivers/net/wireless/ath/ath9k/recv.c:220: warning: comparison is always false due to limited range of data type
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Copied from original one-line patch here:
http://bugzilla.kernel.org/show_bug.cgi?id=14267#c26
(This is for 2.6.33 and beyond, where the bool was changed to a flag by
"cfg80211: convert bools into flags". -- JWL)
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The sign of correction coefficients was lost in the calculations, which
caused high packetloss in 802.11a mode after the results were applied.
Fixed by removing unneccesary and broken AND with a bit mask.
Signed-off-by: Lukas Turek <8an@praha12.net>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It has been tested with a 802.11 frame generator and by checking the FCS field
of each received frame with the value reported by the Atheros hardware. This
patch is useful if you are trying to analyze non standard 802.11 frame going
over the air.
Signed-off-by: Benoit PAPILLAULT <benoit.papillault@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We've accumulated a number of options for wiphys
which make more sense as flags as we keep adding
more. Convert the existing ones.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
At least two revisions of the D-Link DWA 160 exist, called A1 and A2. A1
(USB-ID 07d1:3c10) is already listed in usb.c as D-Link DWA 160A. A2
(USB-ID 07d1:3a09) works if added to ar9170_usb_ids. I didn't do much
testing until now, but I was able to connect to APs using WPA or WEP and
transmit data.
Summary:
* Add model revision number to the comment for D-Link DWA 160 A1 (07d1:3c10)
* Add support for D-Link DWA 160 A2 (07d1:3a09)
Signed-off-by: Thomas Klute <thomas2.klute@uni-dortmund.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The entire aggregation code currently operates on the
hw pointer and station addresses, but that needs to
change to make stations purely per-vif; As one step
preparing for that make the aggregation code callable
with the station, or by the combination of virtual
interface and station address.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Check for AR5416 ver 1.0 before calibrating 3 chains
for multi-chain. This is a WAR for calibration
failure.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ATH9K_ANT_VARIABLE is the default diversity control used.
Consequently ath9k_hw_decrease_chain_power() does nothing.
ath9k_hw_setantennaswitch() is unused too.
Also, gbeacon_rate is unused.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
axq_linkbuf, axq_aggr_depth, axq_lastdsWithCTS and
axq_gatingds are unused.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Remove a code chunk dealing with operating mode changes.
As noted, all such policy changes are to be done in
add_interface.
* Remove pointless check for empty BSSID.
Also, remove mode checks - mac80211 does all the needed checks.
* Handle enabling/disabling beacon transmission properly.
* Handle beacon interval changes for AP mode.
The original code depended on config_interface() to update
the HW TSF. Since that callback has been removed, handle
it properly.
* Remove unneeded code dealing with key/privacy.
* Set the chainmasks to 1x1 for IBSS when the BSSID is set.
This was happening uncondionally before.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch removes the need for separately allocated private tx info
data in ath9k and brings the driver one small step closer to using the
mac80211 rate control API properly.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch enables the driver to process all incoming
dupofdm-modulated frames when operating in HT40 mode.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As a holdover from earlier code when we used to set
the power limit to '0' after a reset to configure the
default transmit power, ath5k interprets txpower=0 as
12.5 dBm. Fix that by just passing 0 through.
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=14567
Cc: stable@kernel.org
Reported-by: Daniel Folkers <daniel.folkers@task24.nl>
Tested-by: Daniel Folkers <daniel.folkers@task24.nl>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a regression introduced in
"ath9k: avoid the copy skb->cb on every RX'd skb"
With that change, the rx status in skb->cb was left uninitialized
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The bit value of AR_GPIO_INPUT_EN_VAL_BT_PRIORITY_BB is wrong, it should
be 0x400 and the number of bits to be right shifted is 10. Having this
wrong value in 0x4054 sometimes affects bt quality on btcoex environment.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jumbograms are frames put together linked together through
more than one descriptor. For example ath9k_htc will use this
to send from the target a large frame split up into 2 or more
segments. The driver then would be in charge of putting the
frame back together.
When jumbograms are constructed the rx_stats->rs_more will
bet set and rx_stats->rs_status will not have any valid content
as the actual status will only be avialable at the end of
the chained descriptors.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is now deprecated and unused within mac80211, so time
to remove it as otherwise we'd be doing some unecessary
computations for nothing.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k and ath9k_htc share a lot of common hardware characteristics.
They only differ in that ath9k_htc works with a target CPU and ath9k
works directly with the hardware. ath9k_htc will do *some* things in
the firmware, but a lot of others on the host.
The common 802.11n hardware code is already shared through the ath9k_hw
module. Common helpers amongst all Atheros drivers can use the ath module,
this includes ath5k and ar9170 as users. But there is some common driver
specific helpers which are not exactly hardware code which ath9k and
ath9k_htc can share. We'll be using ath9k_common for this to avoid
bloating the ath module and the common 802.11n hardware module ath9k_hw.
We start by sharing skb pre and post processing in preparation for a hand
off to mac80211.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use a helper for the RX skb post processing,
ath9k_rx_skb_postprocess().
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This will make sharing code easier between ath9k and ath9k_htc.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
And change the return value to something more obvious.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
While at it flip the order, seems easier to read and also
add some better description as to why we do this check.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath5k is using the (csz - 1) twice as ath_rxbuf_alloc() already allocates
and moves skb->data accordingly. Remove the extra (csz -1).
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This will also be used by ath9k_htc.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The skb->cb (control buffer, 48 bytes) is available to the skb
upon skb allocation. You can fill it up imediately after skb
allocation. ath9k was copying onto the skb->cb the data from the
processed skb for mac80211 from a stack struct ieee80211_rx_status
structure. This is unnecessary, instead use the skb->cb for the
rx status immediately after the skb becomes available and DMA
synched.
Additionally, avoid the copy of the skb->cb also for virtual wiphys
as skb_copy() will copy over the skb->cb for us as well.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This moves all the RX processing of RSSI into a helper,
ath_rx_prepare(). ath_rx_prepare() should now be really
easy to read and follow.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This moves the qual computing into a small helper,
ath9k_compute_qual()
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_process_rate() now does all the rx status processing to
read the rate the hardware passed and translate it to whatever
mac80211 wants.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Its just a distraction when reading the code, instead use the
rx_stats->rs_rate directly.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This does sanity checking on the skb and RX status descriptor
prior to processing.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Pavel Roskin