- 07 4月, 2010 1 次提交
-
-
由 Pavel Roskin 提交于
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>
-
- 01 4月, 2010 2 次提交
-
-
由 Felix Fietkau 提交于
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>
-
由 Felix Fietkau 提交于
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>
-
- 17 3月, 2010 1 次提交
-
-
由 Felix Fietkau 提交于
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>
-
- 11 3月, 2010 1 次提交
-
-
由 Felix Fietkau 提交于
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>
-
- 03 3月, 2010 1 次提交
-
-
由 Ming Lei 提交于
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>
-
- 10 2月, 2010 1 次提交
-
-
由 Sujith 提交于
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>
-
- 09 2月, 2010 1 次提交
-
-
由 Senthil Balasubramanian 提交于
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: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 02 2月, 2010 1 次提交
-
-
由 Pavel Roskin 提交于
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: NPavel Roskin <proski@gnu.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 20 1月, 2010 1 次提交
-
-
由 Felix Fietkau 提交于
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: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 13 1月, 2010 1 次提交
-
-
由 Sujith 提交于
sc_flags has slowly become a kitchen sink over time. Move powersave related flags to a separate variable. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 29 12月, 2009 1 次提交
-
-
由 Felix Fietkau 提交于
My previous change added in: commit 815833e7 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: NBjörn Smedman <bjorn.smedman@venatech.se> Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 22 12月, 2009 3 次提交
-
-
由 Sujith 提交于
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: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
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: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Benoit Papillault 提交于
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: NBenoit PAPILLAULT <benoit.papillault@free.fr> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 08 12月, 2009 1 次提交
-
-
由 Felix Fietkau 提交于
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: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 29 11月, 2009 3 次提交
-
-
由 Benoit Papillault 提交于
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: NBenoit Papillault <benoit.papillault@free.fr> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
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: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NVivek Natarajan <Vivek.Natarajan@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
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: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 19 11月, 2009 2 次提交
-
-
由 Sujith 提交于
axq_linkbuf, axq_aggr_depth, axq_lastdsWithCTS and axq_gatingds are unused. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
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: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 12 11月, 2009 3 次提交
-
-
由 Luis R. Rodriguez 提交于
ath9k virtual wiphys all share the same internal buffer space for TX but they do not share the mac80211 skb queues. When ath9k detects it is running low on buffer space to TX it tells mac80211 to stop sending it skbs its way but it always does this only for the primary wiphy. This means mac80211 won't know its best to avoid sending ath9k more skbs on a separate virtual wiphy. The same issue is present for reliving the skb queue. Since ath9k does not keep track of which virtual wiphy is hammering on TX silence all wiphy's TX when we're low on buffer space. When we're free on buffer space only bother informing the virtual wiphy which is active that we have free buffers. Cc: Jouni.Malinen <Jouni.Malinen@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
When using virtual wiphys the base sc->hw was being used, the correct hw is passed along the caller already so just use that. Cc: Jouni.Malinen <Jouni.Malinen@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
When ath9k virtual wiphys are used the sc->hw will not always represent the active hw, instead we need to get it from the skb->cb private driver area. This ensures the right hw is used to find a sta for the TX'd skb. Cc: Jouni.Malinen <Jouni.Malinen@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 05 11月, 2009 1 次提交
-
-
由 Johannes Berg 提交于
Since we have a TODO item to make all station management dependent on virtual interfaces, I figured I'd start with pushing such a change to drivers before more drivers start using the ieee80211_find_sta() API with a hw pointer and cause us grief later on. For now continue exporting the old API in form of ieee80211_find_sta_by_hw(), but discourage its use strongly. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 28 10月, 2009 1 次提交
-
-
由 Sujith 提交于
When TX is hung, the chip is reset. Ensure that the chip is awake by using the PS wrappers. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 08 10月, 2009 4 次提交
-
-
由 Luis R. Rodriguez 提交于
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
ath9k uses this for now, ath9k_htc is expected to re-use this as well. We lave ath5k as is, but it certainly can also be converted later. The ath9k module parameter and debugfs entry is kept. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
DPRINTF() is used in hw specific related code, as such ensure we don't rely on the private driver core ath_softc struct when calling it. Drivers can then implement their own DPRINTF() as they see fit. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 29 8月, 2009 1 次提交
-
-
This patch adds 3-wire bluetooth coex support for AR9285. This support can be enabled through btcoex_enable modparam. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 05 8月, 2009 1 次提交
-
-
由 Luis R. Rodriguez 提交于
The mac80211 workqueue exists to enable mac80211 and drivers to queue their own work on a single threaded workqueue. mac80211 takes care to flush the workqueue during suspend but we never really had requirements on drivers for how they should use the workqueue in consideration for suspend. We extend mac80211 to document how the mac80211 workqueue should be used, how it should not be used and finally move raw access to the workqueue to mac80211 only. Drivers and mac80211 use helpers to queue work onto the mac80211 workqueue: * ieee80211_queue_work() * ieee80211_queue_delayed_work() These helpers will now warn if mac80211 already completed its suspend cycle and someone is trying to queue work. mac80211 flushes the mac80211 workqueue prior to suspend a few times, but we haven't taken the care to ensure drivers won't add more work after suspend. To help with this we add a warning when someone tries to add work and mac80211 already completed the suspend cycle. Drivers should ensure they cancel any work or delayed work in the mac80211 stop() callback. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 30 7月, 2009 1 次提交
-
-
由 Sujith 提交于
Location: ath9k/phy#/xmit Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 28 7月, 2009 3 次提交
-
-
由 Sujith 提交于
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
Cleanup aggregation start/stop function interfaces. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 25 7月, 2009 3 次提交
-
-
Update tx BA window and complete the frame as failed one if we can't clone the holding descriptor due to unavailability of descriptors. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
oops, this one should be part of the original patch "ath9k: downgrade assert in ath_clone_txbuf()" Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
The hardware doesn't generate interrupts in some cases and so work around this by monitoring the TX status periodically and reset the chip if required. This behavior of the hardware not generating the TX interrupts can be noticed through ath9k debugfs interrupt statistics when heavy traffic is being sent from STA to AP. One can easily see this behavior when the STA is transmitting at a higher rates. The interrupt statistics in the debugfs interface clearly shows that only RX interrupts alone being generated and TX being stuck. TX should be monitored through a timer and reset the chip only when frames are queued to the hardware but TX interrupts are not generated for the same even after one second. Also, we shouldn't remove holding descriptor from AC queue if it happens to be the only descriptor and schedule TX aggregation regarless of queue depth as it improves scheduling of AMPDUs from software to hardware queue. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 11 7月, 2009 1 次提交
-
-
We can easily run out of tx buf if there is any stuck in transmission, so downgrade it to WARN_ON(). Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-