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: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn 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: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When ath_tx_complete_aggr() is called, it's responsible for returning
all buffers in the linked list. This was not done when the STA lookup
failed, leading to a race condition that could leak a few buffers when
a STA just disconnected.
Fix this by immediately returning all buffers to the free list in this case.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It looks like it might be possible for a TID to be paused, while still
holding some queued buffers, however ath_tx_node_cleanup currently only
iterates over active TIDs.
Fix this by always checking every allocated TID for the STA that is being
cleaned up.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The 'bf_retries' field of the ath_buf structure was used for both
software retries (AMPDU subframes) and hardware retries (legacy
frames). This led to a wrong retry count being reported for the A-MPDU
rate control stats.
This patch changes the code to no longer use bf_retries for reporting
retry counts, but instead always using the real on-chip retry count
from the ath_tx_status.
Additionally, if the first subframe of an A-MPDU was not acked, the tx
status report is submitted along with the first acked subframe, which
may not contain the correct rates in the tx info.
This is easily corrected by saving the tx rate info before looping over
subframes, and then copying it back once the A-MPDU status report is
submitted.
In my tests this change improves throughput visibly.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Reported-by: NBjörn Smedman <bjorn.smedman@venatech.se>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It is possbile that the transmission of paprd test frame
might not get completed in 100ms if tx is stuck. Freeing
this skb upon timeout in ath_paprd_calibrate() will result
in accessing already freed memory when the associated pending
buffer is drained in txq. This patch fixes this issue.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k tries to prevent WMM queue tx buffer starvation caused by
traffic on different queues by limiting the number of pending frames
in a tx queue (tracked in the ath_buf structure). This had a leak
issue, because the a skb can be reassigned to a different ath_buf
in the tx path, causing the pending frame counter to become inaccurate.

To fix this, track the number of frames in an array in the softc,
using the mac80211 queue mapping as index.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath_get_mac80211_qnum() expects the queue 'subtype'
(internal ID for the WMM AC) as argument when looking up
the mac80211 queue, however ath_wake_mac80211_queue provides
txq->axq_qnum instead, which contains the hardware queue
number. Fix this by keeping track of the WMM class ID in
the txq data structure.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Because there is a limited number of tx buffers available, once the
queue has been filled to a certain point, ath9k needs to stop accepting
new frames from mac80211. In order to prevent a full WMM queue from
stopping another queue with fewer frames, this patch limits the number
of queued frames to a quarter of the total available tx buffers, minus
some reserved frames to be used for other purposes (e.g. beacons).

Because tx buffers are reserved for frames when they're staged in
software queues as well, the actual queue depth cannot be used for
this, so this patch stores a reference to the tx queue in the ath_buf
struct and keeps track of the total number of pending frames.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add missing code to handle nullfunc frame completion in
ath_tx_edma_tasklet().
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This bug was introduced by the following commit

	Author: Vasanthakumar Thiagarajan <vasanth@atheros.com>
	Date:   Thu Apr 15 17:38:46 2010 -0400

	ath9k: Remove ATH9K_TX_SW_ABORTED and introduce a bool for this purpose

Wrong buffer is checked for bf_tx_aborted field in ath_tx_num_badfrms(),
this may result in a rate scaling with wrong feedback (number
of unacked frames in this case). It is the last one in the chain
of buffers for an aggregate frame that should be checked.

Also it misses the initialization of this field in the buffer,
this may lead to a situation where we stop the sw retransmission
of failed subframes associated to this buffer.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath_print in xmit.c should say "Reseting hardware"
instead of Resetting HAL!(since HAL is being fazed out).
dmesg shows:
[ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 8660.899676] ath: Unable to stop TxDMA. Reset HAL!
Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Supported only for single stream rates by the hardware
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of increasing bits_per_symbol for supporting more streams, keep
it single-stream only and multiply the values by the numer of streams.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Include MCS0-31 and also add SGI for HT20. This makes it
possible to support more different rate combinations with
newer hardware.

Based on a patch by Selvam. T.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

LDPC is enabled by the rate control if the its determined
that the target peer supports LDPC. We would have already
intersected the HT capabilities so if our peer supports
LDPC so do we.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Also add a function to clean up tx status ring.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Symbols starting with "ATH9K_INT" are also used for interrupt mask.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath_tx_status and ath_rx_status data are only necessary for a short
time, until they have been processed and converted into mac80211 data
structures.
Because of that, it makes no sense to keep them tied to the DMA
descriptor, that only wastes precious memory.
This patch allocates the data on stack in the functions that call the
conversion functions from ath9k_hw.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch passes in a pointer to the ath_tx_status data structure for
functions that need it, instead of letting them grab it directly from
the ath_desc struct. This is useful for making it possible to allocate
the intermediate tx status data separately.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When I initially stumbled upon sequence number problems with PAE frames
in ath9k, I submitted a patch to remove all special cases for PAE
frames and let them go through the normal transmit path.
Out of concern about crypto incompatibility issues, this change was
merged instead:

commit 6c8afef5
Author: Sujith <Sujith.Manoharan@atheros.com>
Date:   Tue Feb 9 10:07:00 2010 +0530

    ath9k: Fix sequence numbers for PAE frames

After a lot of testing, I'm able to reliably trigger a driver crash on
rekeying with current versions with this change in place.
It seems that the driver does not support sending out regular MPDUs with
the same TID while an A-MPDU session is active.
This leads to duplicate entries in the TID Tx buffer, which hits the
following BUG_ON in ath_tx_addto_baw():

    index  = ATH_BA_INDEX(tid->seq_start, bf->bf_seqno);
    cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1);

    BUG_ON(tid->tx_buf[cindex] != NULL);

I believe until we actually have a reproducible case of an
incompatibility with another AP using no PAE special cases, we should
simply get rid of this mess.

This patch completely fixes my crash issues in STA mode and makes it
stay connected without throughput drops or connectivity issues even
when the AP is configured to a very short group rekey interval.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently the rate control tx status update gets called for every
subframe of an A-MPDU, and ath9k marks the frame with the relevant
status update with an internal flag. This not suitable for rate control
algorithms using the standard mac80211 rate control API, so fix this by
using IEEE80211_TX_STAT_AMPDU for marking the correct frames that
should be processed.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since txq->axq_lock may be hold in softirq context, it must be
acquired with spin_lock_bh() instead of spin_lock() if softieq is
enabled.

The patch fixes the lockdep warning below when unloading ath9k modules.

=================================
[ INFO: inconsistent lock state ]
2.6.33-wl #12
---------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
rmmod/3642 [HC0[0]:SC0[0]:HE1:SE1] takes:
 (&(&txq->axq_lock)->rlock){+.?...}, at: [<ffffffffa03568c3>] ath_tx_node_cleanup+0x62/0x180 [ath9k]
{IN-SOFTIRQ-W} state was registered at:
  [<ffffffff8107577d>] __lock_acquire+0x2f6/0xd35
  [<ffffffff81076289>] lock_acquire+0xcd/0xf1
  [<ffffffff813a7486>] _raw_spin_lock_bh+0x3b/0x6e
  [<ffffffffa0356b49>] spin_lock_bh+0xe/0x10 [ath9k]
  [<ffffffffa0358ec7>] ath_tx_tasklet+0xcd/0x391 [ath9k]
  [<ffffffffa0354f5f>] ath9k_tasklet+0x70/0xc8 [ath9k]
  [<ffffffff8104e601>] tasklet_action+0x8c/0xf4
  [<ffffffff8104f459>] __do_softirq+0xf8/0x1cd
  [<ffffffff8100ab1c>] call_softirq+0x1c/0x30
  [<ffffffff8100c2cf>] do_softirq+0x4b/0xa3
  [<ffffffff8104f045>] irq_exit+0x4a/0x8c
  [<ffffffff813acccc>] do_IRQ+0xac/0xc3
  [<ffffffff813a7d53>] ret_from_intr+0x0/0x16
  [<ffffffff81302d52>] cpuidle_idle_call+0x9e/0xf8
  [<ffffffff81008be7>] cpu_idle+0x62/0x9d
  [<ffffffff81391c1a>] rest_init+0x7e/0x80
  [<ffffffff818bbd38>] start_kernel+0x3e8/0x3f3
  [<ffffffff818bb2bc>] x86_64_start_reservations+0xa7/0xab
  [<ffffffff818bb3b8>] x86_64_start_kernel+0xf8/0x107
irq event stamp: 42037
hardirqs last  enabled at (42037): [<ffffffff813a7b21>] _raw_spin_unlock_irqrestore+0x47/0x56
hardirqs last disabled at (42036): [<ffffffff813a72f4>] _raw_spin_lock_irqsave+0x2b/0x88
softirqs last  enabled at (42000): [<ffffffffa0353ea6>] spin_unlock_bh+0xe/0x10 [ath9k]
softirqs last disabled at (41998): [<ffffffff813a7463>] _raw_spin_lock_bh+0x18/0x6e

other info that might help us debug this:
4 locks held by rmmod/3642:
 #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff8132c10d>] rtnl_lock+0x17/0x19
 #1:  (&wdev->mtx){+.+.+.}, at: [<ffffffffa01e53f2>] cfg80211_netdev_notifier_call+0x28d/0x46d [cfg80211]
 #2:  (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0260834>] ieee80211_mgd_deauth+0x3f/0x17e [mac80211]
 #3:  (&local->sta_mtx){+.+.+.}, at: [<ffffffffa025a381>] sta_info_destroy_addr+0x2b/0x5e [mac80211]

stack backtrace:
Pid: 3642, comm: rmmod Not tainted 2.6.33-wl #12
Call Trace:
 [<ffffffff81074469>] valid_state+0x178/0x18b
 [<ffffffff81014f94>] ? save_stack_trace+0x2f/0x4c
 [<ffffffff81074e08>] ? check_usage_backwards+0x0/0x88
 [<ffffffff8107458f>] mark_lock+0x113/0x230
 [<ffffffff810757f1>] __lock_acquire+0x36a/0xd35
 [<ffffffff8101018d>] ? native_sched_clock+0x2d/0x5f
 [<ffffffffa03568c3>] ? ath_tx_node_cleanup+0x62/0x180 [ath9k]
 [<ffffffff81076289>] lock_acquire+0xcd/0xf1
 [<ffffffffa03568c3>] ? ath_tx_node_cleanup+0x62/0x180 [ath9k]
 [<ffffffff810732eb>] ? trace_hardirqs_off+0xd/0xf
 [<ffffffff813a7193>] _raw_spin_lock+0x36/0x69
 [<ffffffffa03568c3>] ? ath_tx_node_cleanup+0x62/0x180 [ath9k]
 [<ffffffffa03568c3>] ath_tx_node_cleanup+0x62/0x180 [ath9k]
 [<ffffffff810749ed>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffffa0353950>] ath9k_sta_remove+0x22/0x26 [ath9k]
 [<ffffffffa025a08f>] __sta_info_destroy+0x1ad/0x38c [mac80211]
 [<ffffffffa025a394>] sta_info_destroy_addr+0x3e/0x5e [mac80211]
 [<ffffffffa02605d6>] ieee80211_set_disassoc+0x175/0x180 [mac80211]
 [<ffffffffa026084d>] ieee80211_mgd_deauth+0x58/0x17e [mac80211]
 [<ffffffff813a60c1>] ? __mutex_lock_common+0x37f/0x3a4
 [<ffffffffa01e53f2>] ? cfg80211_netdev_notifier_call+0x28d/0x46d [cfg80211]
 [<ffffffffa026786e>] ieee80211_deauth+0x1e/0x20 [mac80211]
 [<ffffffffa01f47f9>] __cfg80211_mlme_deauth+0x130/0x13f [cfg80211]
 [<ffffffffa01e53f2>] ? cfg80211_netdev_notifier_call+0x28d/0x46d [cfg80211]
 [<ffffffff810732eb>] ? trace_hardirqs_off+0xd/0xf
 [<ffffffffa01f7eee>] __cfg80211_disconnect+0x111/0x189 [cfg80211]
 [<ffffffffa01e5433>] cfg80211_netdev_notifier_call+0x2ce/0x46d [cfg80211]
 [<ffffffff813aa9ea>] notifier_call_chain+0x37/0x63
 [<ffffffff81068c98>] raw_notifier_call_chain+0x14/0x16
 [<ffffffff81322e97>] call_netdevice_notifiers+0x1b/0x1d
 [<ffffffff8132386d>] dev_close+0x6a/0xa6
 [<ffffffff8132395f>] rollback_registered_many+0xb6/0x2f4
 [<ffffffff81323bb8>] unregister_netdevice_many+0x1b/0x66
 [<ffffffffa026494f>] ieee80211_remove_interfaces+0xc5/0xd0 [mac80211]
 [<ffffffffa02580a2>] ieee80211_unregister_hw+0x47/0xe8 [mac80211]
 [<ffffffffa035290e>] ath9k_deinit_device+0x7a/0x9b [ath9k]
 [<ffffffffa035bc26>] ath_pci_remove+0x38/0x76 [ath9k]
 [<ffffffff8120940a>] pci_device_remove+0x2d/0x51
 [<ffffffff8129d797>] __device_release_driver+0x7b/0xd1
 [<ffffffff8129d885>] driver_detach+0x98/0xbe
 [<ffffffff8129ca7a>] bus_remove_driver+0x94/0xb7
 [<ffffffff8129ddd6>] driver_unregister+0x6c/0x74
 [<ffffffff812096d2>] pci_unregister_driver+0x46/0xad
 [<ffffffffa035bae1>] ath_pci_exit+0x15/0x17 [ath9k]
 [<ffffffffa035e1a2>] ath9k_exit+0xe/0x2f [ath9k]
 [<ffffffff8108050a>] sys_delete_module+0x1c7/0x236
 [<ffffffff813a7df5>] ? retint_swapgs+0x13/0x1b
 [<ffffffff810749b5>] ? trace_hardirqs_on_caller+0x119/0x144
 [<ffffffff8109b9f6>] ? audit_syscall_entry+0x11e/0x14a
 [<ffffffff81009bb2>] system_call_fastpath+0x16/0x1b
wlan1: deauthenticating from 00:23:cd:e1:f9:b2 by local choice (reason=3)
PM: Removing info for No Bus:wlan1
cfg80211: Calling CRDA to update world regulatory domain
PM: Removing info for No Bus:rfkill2
PM: Removing info for No Bus:phy1
ath9k 0000:16:00.0: PCI INT A disabled
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NJohn 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: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>