linux/drivers/net/wireless, branch mybooklive

b43: Workaround circular locking in hw-tkip key update callback

2010-04-01T22:58:55Z

commit 96869a39399269a776a94812e9fff3d38b47d838 upstream The TKIP key update callback is called from the RX path, where the driver mutex is already locked. This results in a circular locking bug. Avoid this by removing the lock. Johannes noted that there is a separate bug: The callback still breaks on SDIO hardware, because SDIO hardware access needs to sleep, but we are not allowed to sleep in the callback due to mac80211's RCU locking. Signed-off-by: Michael Buesch Tested-by: Larry Finger Reported-by: kecsa@kutfo.hit.bme.hu Cc: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k: Enable IEEE80211_HW_REPORTS_TX_ACK_STATUS flag for ath9k

2010-04-01T22:58:52Z

commit 05df49865be08b30e7ba91b9d3d94d7d52dd3033 upstream. Signed-off-by: Vivek Natarajan Signed-off-by: John W. Linville Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman

ath9k: Enable TIM timer interrupt only when needed.

2010-04-01T22:58:51Z

commit 3f7c5c10e9dc6bf90179eb9f7c06151d508fb324 upstream. 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 Signed-off-by: John W. Linville Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman

ath9k: fix BUG_ON triggered by PAE frames

2010-04-01T22:58:46Z

commit 4fdec031b9169b3c17938b9c4168f099f457169c upstream. 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 6c8afef551fef87a3bf24f8a74c69a7f2f72fc82 Author: Sujith 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: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

iwlwifi: Silence tfds_in_queue message

2010-04-01T22:58:41Z

commit c8406ea8fa1adde8dc5400127281d497bbcdb84a upstream. Commit a239a8b47cc0e5e6d7416a89f340beac06d5edaa introduced a noisy message, that fills up the log very fast. The error seems not to be fatal (the connection is stable and performance is ok), so make it IWL_DEBUG_TX rather than IWL_ERR. Signed-off-by: Adel Gadllah Acked-by: Reinette Chatre Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

iwlwifi: use dma_alloc_coherent

2010-04-01T22:58:40Z

commit f36d04abe684f9e2b07c6ebe9f77ae20eb5c1e84 upstream. Change pci_alloc_consistent() to dma_alloc_coherent() so we can use GFP_KERNEL flag. Signed-off-by: Stanislaw Gruszka Signed-off-by: Reinette Chatre Signed-off-by: Greg Kroah-Hartman

wl1251: fix potential crash

2010-04-01T22:58:37Z

commit 3f60ebc9d6291863652d564bacc430629271e6a9 upstream. In case debugfs does not init for some reason (or is disabled on older kernels) driver does not allocate stats.fw_stats structure, but tries to clear it later and trips on a NULL pointer: Unable to handle kernel NULL pointer dereference at virtual address 00000000 PC is at __memzero+0x24/0x80 Backtrace: [] (wl1251_debugfs_reset+0x0/0x30 [wl1251]) [] (wl1251_op_stop+0x0/0x12c [wl1251]) [] (ieee80211_stop_device+0x0/0x74 [mac80211]) [] (ieee80211_stop+0x0/0x4ac [mac80211]) [] (dev_close+0x0/0xb4) [] (dev_change_flags+0x0/0x184) [] (devinet_ioctl+0x0/0x704) [] (inet_ioctl+0x0/0x100) Add a NULL pointer check to fix this. Signed-off-by: Grazvydas Ignotas Acked-by: Kalle Valo Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k: fix lockdep warning when unloading module

2010-04-01T22:58:18Z

commit a9f042cbe5284f34ccff15f3084477e11b39b17b upstream. 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: [] ath_tx_node_cleanup+0x62/0x180 [ath9k] {IN-SOFTIRQ-W} state was registered at: [] __lock_acquire+0x2f6/0xd35 [] lock_acquire+0xcd/0xf1 [] _raw_spin_lock_bh+0x3b/0x6e [] spin_lock_bh+0xe/0x10 [ath9k] [] ath_tx_tasklet+0xcd/0x391 [ath9k] [] ath9k_tasklet+0x70/0xc8 [ath9k] [] tasklet_action+0x8c/0xf4 [] __do_softirq+0xf8/0x1cd [] call_softirq+0x1c/0x30 [] do_softirq+0x4b/0xa3 [] irq_exit+0x4a/0x8c [] do_IRQ+0xac/0xc3 [] ret_from_intr+0x0/0x16 [] cpuidle_idle_call+0x9e/0xf8 [] cpu_idle+0x62/0x9d [] rest_init+0x7e/0x80 [] start_kernel+0x3e8/0x3f3 [] x86_64_start_reservations+0xa7/0xab [] x86_64_start_kernel+0xf8/0x107 irq event stamp: 42037 hardirqs last enabled at (42037): [] _raw_spin_unlock_irqrestore+0x47/0x56 hardirqs last disabled at (42036): [] _raw_spin_lock_irqsave+0x2b/0x88 softirqs last enabled at (42000): [] spin_unlock_bh+0xe/0x10 [ath9k] softirqs last disabled at (41998): [] _raw_spin_lock_bh+0x18/0x6e other info that might help us debug this: 4 locks held by rmmod/3642: #0: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x19 #1: (&wdev->mtx){+.+.+.}, at: [] cfg80211_netdev_notifier_call+0x28d/0x46d [cfg80211] #2: (&ifmgd->mtx){+.+.+.}, at: [] ieee80211_mgd_deauth+0x3f/0x17e [mac80211] #3: (&local->sta_mtx){+.+.+.}, at: [] sta_info_destroy_addr+0x2b/0x5e [mac80211] stack backtrace: Pid: 3642, comm: rmmod Not tainted 2.6.33-wl #12 Call Trace: [] valid_state+0x178/0x18b [] ? save_stack_trace+0x2f/0x4c [] ? check_usage_backwards+0x0/0x88 [] mark_lock+0x113/0x230 [] __lock_acquire+0x36a/0xd35 [] ? native_sched_clock+0x2d/0x5f [] ? ath_tx_node_cleanup+0x62/0x180 [ath9k] [] lock_acquire+0xcd/0xf1 [] ? ath_tx_node_cleanup+0x62/0x180 [ath9k] [] ? trace_hardirqs_off+0xd/0xf [] _raw_spin_lock+0x36/0x69 [] ? ath_tx_node_cleanup+0x62/0x180 [ath9k] [] ath_tx_node_cleanup+0x62/0x180 [ath9k] [] ? trace_hardirqs_on+0xd/0xf [] ath9k_sta_remove+0x22/0x26 [ath9k] [] __sta_info_destroy+0x1ad/0x38c [mac80211] [] sta_info_destroy_addr+0x3e/0x5e [mac80211] [] ieee80211_set_disassoc+0x175/0x180 [mac80211] [] ieee80211_mgd_deauth+0x58/0x17e [mac80211] [] ? __mutex_lock_common+0x37f/0x3a4 [] ? cfg80211_netdev_notifier_call+0x28d/0x46d [cfg80211] [] ieee80211_deauth+0x1e/0x20 [mac80211] [] __cfg80211_mlme_deauth+0x130/0x13f [cfg80211] [] ? cfg80211_netdev_notifier_call+0x28d/0x46d [cfg80211] [] ? trace_hardirqs_off+0xd/0xf [] __cfg80211_disconnect+0x111/0x189 [cfg80211] [] cfg80211_netdev_notifier_call+0x2ce/0x46d [cfg80211] [] notifier_call_chain+0x37/0x63 [] raw_notifier_call_chain+0x14/0x16 [] call_netdevice_notifiers+0x1b/0x1d [] dev_close+0x6a/0xa6 [] rollback_registered_many+0xb6/0x2f4 [] unregister_netdevice_many+0x1b/0x66 [] ieee80211_remove_interfaces+0xc5/0xd0 [mac80211] [] ieee80211_unregister_hw+0x47/0xe8 [mac80211] [] ath9k_deinit_device+0x7a/0x9b [ath9k] [] ath_pci_remove+0x38/0x76 [ath9k] [] pci_device_remove+0x2d/0x51 [] __device_release_driver+0x7b/0xd1 [] driver_detach+0x98/0xbe [] bus_remove_driver+0x94/0xb7 [] driver_unregister+0x6c/0x74 [] pci_unregister_driver+0x46/0xad [] ath_pci_exit+0x15/0x17 [ath9k] [] ath9k_exit+0xe/0x2f [ath9k] [] sys_delete_module+0x1c7/0x236 [] ? retint_swapgs+0x13/0x1b [] ? trace_hardirqs_on_caller+0x119/0x144 [] ? audit_syscall_entry+0x11e/0x14a [] 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: Ming Lei Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath5k: fix setup for CAB queue

2010-04-01T22:58:08Z

commit a951ae2176b982574ffa197455db6c89359fd5eb upstream. 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 Acked-by: Nick Kossifidis Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath5k: dont use external sleep clock in AP mode

2010-04-01T22:58:07Z

commit 5d6ce628f986d1a3c523cbb0a5a52095c48cc332 upstream 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 Acked-by: Nick Kossifidis Signed-off-by: John W. Linville Cc: Luis Rodriguez Signed-off-by: Greg Kroah-Hartman