The HW has to be awake when accessing registers.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add support to change interface type
without bringing down the interface.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 will notify drivers when to go idle and ath9k
assumed that it would get further notifications for idle
states after a device stop() config call but as per agreed
semantics the idle state of the radio is left up to driver
after mac80211 issues the stop() callback. The driver is
resposnbile for ensuring the device remains idle after
that even between suspend / resume calls.
This fixes suspend/resume when you issue suspend and resume
twice on ath9k when ath9k_stop() was already called. We need
to put the radio to full sleep in order for resume to work
correctly.
What might seem fishy is we are turning the radio off
after resume. The reason why we do this is because we know
we should not have anything enabled after a mac80211 tells
us to stop(), if we resume and never get a start() we won't
get another stop() by mac80211 so to be safe always bring
the 802.11 device with the radio disabled after resume,
this ensures that if we suspend we already have the radio
disabled and only a start() will ever trigger it on.
Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Upon a failure we never call ath9k_ps_restore() on ath_radio_enable(),
this will throw off the sc->ps_usecount. When the sc->ps_usecount
is > 0 we never put the chip to full sleep. This drains battery,
and will also make the chip fail upon resume with:
ath: Starting driver with initial channel: 5745 MHz
ath: timeout (100000 us) on reg 0x7000: 0xdeadbeef & 0x00000003 != 0x00000000
This would make the chip useless upon resume.
I cannot prove this can happen but in theory it is so best to
avoid this race completely and not have users complain about
a broken device after resume.
Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We should not be idle when we get the ATH9K_INT_TIM_TIMER,
otherwise its a sign of something broken in our design with
our idle state machine and mac80211. Skip these and WARN once
just in case this is triggerable.
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove ath/debug.h and the includes of these files.
Coalesce long formats.
Correct a few misspellings and missing "\n"s from these logging messages.
Remove unnecessary trailing space before a newline.
Remove ARRAY_SIZE casts, use printf type %zu
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
So these errors are always emitted at KERN_ERR level.
Remove ARRAY_SIZE casts, use printf type %zu
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The beacon tasklet is accesssing the bslot info for beacon generation.
Meanwhile the same slot can be freed on interface deletion.
Current the remove_interface disables the beacon alert after freeing the slot.
This may leads to null pointer access.
This patch disables SWBA and kills the beacon tasklet to prevent access
to the slot to be freed. After releasing the slot, swba will be enabled again
upon the availablity of beaconing interfaces.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When ath_drain_all_txq fails to stop DMA, it issues a hw reset. This reset
happens at a very problematic point in time, when the hardware rx path has
not been stopped yet. This could lead to memory corruption, hardware hangs
or other issues.
To fix these issues, simply remove the reset entirely and check the tx DMA
stop status to prevent problems with fast channel changes.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This feature is to mitigate the problem of certain 3
stream chips that exceed the PCIe power requirements.An EEPROM flag
controls which chips have APM enabled which is basically read from
miscellaneous configuration element of the EEPROM header.
This workaround will reduce power consumption by using 2 Tx chains for
Single and Double stream rates (5 GHz only).All self generated frames
(regardless of rate) are sent on 2 chains when this feature is
enabled(Chip Limitation).
Cc: Paul Shaw <paul.shaw@atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Tested-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
while removing beaconing mode interface, SWBA interrupt
was never disabled when there are no other beaconing interfaces.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The ath9k driver uses a shared pm_qos_request_list structure for all
devices. This causes the following warning if more than one device is
present in the system:
WARNING: at kernel/pm_qos_params.c:234 ath9k_init_device+0x5e8/0x6b0()
pm_qos_add_request() called for already added request
Modules linked in:
Call Trace:
[<802b1cdc>] dump_stack+0x8/0x34
[<8007dd90>] warn_slowpath_common+0x78/0xa4
[<8007de44>] warn_slowpath_fmt+0x2c/0x38
[<801b0828>] ath9k_init_device+0x5e8/0x6b0
[<801bc508>] ath_pci_probe+0x2dc/0x39c
[<80176254>] pci_device_probe+0x64/0xa4
[<8019471c>] driver_probe_device+0xbc/0x188
[<80194854>] __driver_attach+0x6c/0xa4
[<80193e20>] bus_for_each_dev+0x60/0xb0
[<80193580>] bus_add_driver+0xcc/0x268
[<80194c08>] driver_register+0xe0/0x198
[<801764e0>] __pci_register_driver+0x50/0xe0
[<80365f48>] ath9k_init+0x3c/0x6c
[<8006050c>] do_one_initcall+0xfc/0x1d8
[<80355340>] kernel_init+0xd4/0x174
[<800639a4>] kernel_thread_helper+0x10/0x18
---[ end trace 5345fc6f870564a6 ]---
This patch fixes that warning by using a separate pm_qos_request_list
sructure for each device.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Merge initial processing for the CAB queue and regular tx.
Also move ath_tx_cabq() to beacon.c and make it static.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The current ath9k tx queue handling code showed a few issues that could
lead to locking issues, tx stalls due to stopped queues, and maybe even
DMA issues.
The main source of these issues is that in some places the queue is
selected via skb queue mapping in places where this mapping may no
longer be valid. One such place is when data frames are transmitted via
the CAB queue (for powersave buffered frames). This is made even worse
by a lookup WMM AC values from the assigned tx queue (which is
undefined for the CAB queue).
This messed up the pending frame counting, which in turn caused issues
with queues getting stopped, but not woken again.
To fix these issues, this patch removes an unnecessary abstraction
separating a driver internal queue number from the skb queue number
(not to be confused with the hardware queue number).
It seems that this abstraction may have been necessary because of tx
queue preinitialization from the initvals. This patch avoids breakage
here by pushing the software <-> hardware queue mapping to the function
that assigns the tx queues and redefining the WMM AC definitions to
match the numbers used by mac80211 (also affects ath9k_htc).
To ensure consistency wrt. pending frame count tracking, these counters
are moved to the ath_txq struct, updated with the txq lock held, but
only where the tx queue selected by the skb queue map actually matches
the tx queue used by the driver for the frame.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Björn Smedman <bjorn.smedman@venatech.se>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This helps align resets / RX enable & disable / TX stop / start.
Locking around the PCU is important to ensure the hardware doesn't
get stale data when working with DMA'able data.
This is part of a series of patches which fix stopping
TX DMA completley when requested on the driver.
For more details about this issue refer to this thread:
http://marc.info/?l=linux-wireless&m=128629803703756&w=2
Tested-by: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The PCU lock should be used to contend TX DMA as well,
this will be done next.
This is part of a series of patches which fix stopping
TX DMA completley when requested on the driver.
For more details about this issue refer to this thread:
http://marc.info/?l=linux-wireless&m=128629803703756&w=2
Tested-by: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The new PCU lock is better placed so we can just contend
against that when trying to reset hardware.
This is part of a series of patches which fix stopping
TX DMA completley when requested on the driver.
For more details about this issue refer to this thread:
http://marc.info/?l=linux-wireless&m=128629803703756&w=2
Tested-by: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw_set_txpowerlimit gets an extra boolean parameter that - if set -
causes the rate txpower table and the regulatory limit to be calculated
and stored, without changing hardware registers.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ANI needs the RSSI average only in station mode, and only for tracking
the signal strength of beacons of the AP that it is connected to.
Adjust the code to track on the beacon RSSI, and store the average of that
in the ath_wiphy struct.
With these changes, we can get rid of this extra station lookup in the
rx path, which saves precious CPU cycles.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
OProfile showed that ath9k was spending way too much time in
ath9k_hw_set_interrupts. Since most of the interrupt mask changes only
need to globally enable/disable interrupts, it makes sense to split
this part into separate functions, replacing all calls to
ath9k_hw_set_interrupts(ah, 0) with ath9k_hw_disable_interrupts(ah).
ath9k_hw_set_interrupts(ah, ah->imask) only gets changed to
ath9k_hw_enable_interrupts(ah), whenever ah->imask was not changed
since the point where interrupts were disabled.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_ps_wakeup() clears the cycle counters after waking up the
hardware using ath9k_hw_setpower, however if power save is disabled,
then the counters will contain useful data, which then gets discarded.
Fix this by checking the old power mode before discarding any data.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Throughput was severely affected in Intel Pinetrail platforms
because of a DMA problem in C3 state. This patch fixes this
issue.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
CC: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The HW opmode is blindly set to monitor type on monitor mode
change notification. This overrides the opmode when one of the
interfaces is still running as non-monitor iftype. So the monitoring
information needs to be maintained seperately.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Apart from locking the start and stop PCU we need
to ensure we also content starting and stopping the PCU
between hardware resets.
This is part of a series that will help resolve the bug:
https://bugzilla.kernel.org/show_bug.cgi?id=14624
For more details about this issue refer to:
http://marc.info/?l=linux-wireless&m=128629803703756&w=2
Cc: stable@kernel.org
Cc: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The real way to lock RX is to contend on the PCU
and reset, this will be fixed in the next patch but for
now just do the renames so that the next patch which changes
the locking order is crystal clear.
This is part of a series that will help resolve the bug:
https://bugzilla.kernel.org/show_bug.cgi?id=14624
For more details about this issue refer to:
http://marc.info/?l=linux-wireless&m=128629803703756&w=2
Cc: stable@kernel.org
Cc: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since aggregation is usually triggered by tx completion, a hardware
reset (because of beacon stuck, tx hang or baseband hang) can
significantly delay the transmission of the next AMPDU (until the next
tx completion event).
Fix this by rescheduling aggregation after such a reset.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If ah->curchan is uninitialized, the channel index is bogus, which leads
to invalid memory access when the cycle counters are updated.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Set the rate table in the rc module properly based on band and
HT capabilities instead, which was already partially done, but
not for every mode.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_hw_proc_mib_event updates the cycle counters, so it common->cc_lock
must be acquired.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
While the chip is in powersave mode, the cycle counter updates do not
contain useful values. While the chip is in full sleep, the rx_clear
signal stays high, indicating a busy medium.
To ensure sane values, update cycle counters before going into
powersave, and clear them right after switching back to awake.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This allows mac80211 to enable receiving of Probe Request frames in
station mode which is needed for P2P.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Results for the active channel are updated whenever a new survey dump
is requested, the old data is kept to allow multiple processes to
make their own channel utilization averages.
All other channels only contain the data for the last time that the
hardware was on the channel, i.e. the last scan result or other
off-channel activity.
Running a background scan does not clear the data for the active
channel.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Instead of keeping track of wraparound, clear the counters on every
access and keep separate deltas for ANI and later survey use.
Also moves the function for calculating the 'listen time' for ANI
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
drv_config callback is called only after the ack for the nullframe
is received and so driver need not do anything special for this.
So remove NULLFUNC_COMPLETED, PS_ENABLED flags and bf_isnullfunc
flags from ath9k as mac80211 already handles them properly.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Split out the PHY error counter update from ath9k_hw_ani_monitor_*, reuse
it in ath9k_hw_proc_mib_event (merged from ath9k_hw_proc_mib_event_old
and ath9k_hw_proc_mib_event_new).
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
common->ani.noise_floor is now only used for a similar redundant debug
message similar to the one that was removed from ath9k_htc in an earlier
patch. Remove it from ath9k as well now.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Paprd needs to be done only on active chains(not for all the chains
that hw can support). The paprd training frames which are sent
for inactive chains would be hanging on the hw queue without
getting transmitted and would make the connection so unstable.
This issue happens only with the hw which supports paprd cal(ar9003).
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
A new aggregation session start can be issued by mac80211, even when the
cleanup of the previous session has not completed yet. Since the data structure
for the session is not recreated, this could corrupt the block ack window
and lock up the aggregation session. Fix this by delaying the new session
until the old one has been cleaned up.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k's entire logic with SC_OP_SCANNING is incorrect due to the
way mac80211 currently implements the scan complete callback and
we handle it in ath9k. This patch removes the flag completely in
preference for the SC_OP_OFFCHANNEL which is really what we wanted.
The scanning flag was used to ensure we reset ANI to the old values
when we go back to the home channel, but if we are offchannel we
use some defaults. The flag was also used to re-enable the TX monitor.
Without this patch we simply never re-enabled ANI and the TX monitor
after going offchannel. This means that after one background
scan we are prone to noise issues and if we had a TX hang we would
not recover. To get this to work properly we must enable ANI after
we have configured the beacon timers, otherwise hardware acts really
oddly.
This patch has stable fixes which apply down to [2.6.36+], there
*may* be a to fix this on older kernels but requires a bit of
work since this patch relies on the new mac80211 flag
IEEE80211_CONF_OFFCHANNEL which was introduced as of 2.6.36.
Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When we return to the home channel we were never reseting our beacon
timers, this was casued by the fact that the scanning flag was still
on even after we returned to our home channel. There are also other
reasons why we would get a reset and if we are not off channel
we always need to resynch our beacon timers, because a reset will
clear them.
This bug is a regression introduced on 2.6.36. The order of the
changes are as follows:
5ee08656 - Sat Jul 31 - ath9k: prevent calibration during off-channel activity
a0daa0e7 - Tue Jul 27 - Revert "mac80211: fix sw scan bracketing"
543708be - Fri Jun 18 - mac80211: fix sw scan bracketing
mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \
--contains 5ee0865615
v2.6.36-rc1~43^2~34^2~22
mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \
--contains a0daa0e759
v2.6.36-rc1~571^2~64^2~13
mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \
--contains 543708be32
v2.6.36-rc1~571^2~107^2~187
So 5ee08656 would have worked if a0daa0e7 was not committed but
it was so this means 5ee08656 was broken since it assumed that
when we were in the channel change routine the scan flag would
be lifted. As it turns out the scan flag will be set when we
are already on the home channel.
For more details refer to:
http://code.google.com/p/chromium-os/issues/detail?id=5715
These issues will need to be considered for our solution on
reshifting the scan complete callback location on mac80211 on
current development kernel work.
This patch has stable fixes which apply down to [2.6.36+]
Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sujith Manoharan