linux/drivers/net/wireless, branch v4.7

Merge tag 'wireless-drivers-for-davem-2016-06-21' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers

2016-06-23T19:22:31Z

Kalle Valo says: ==================== wireless-drivers fixes for 4.7 iwlwifi * fix the scan timeout for long scans * fix an RCU splat caused when updating the TKIP key * fix a potential NULL-derefence introduced recently * fix a IGTK key bug that has existed since the MVM driver was introduced * fix some fw capabilities checks that got accidentally inverted rtl8xxxu * fix typo on variable name ath10k * fix deadlock when peer cannot be created * fix crash related to printing features * fix deadlock while processing rx_in_ord_ind ath9k * fix GPIO mask regression for AR9462 and AR9565 ==================== Signed-off-by: David S. Miller

Merge ath-current from ath.git

2016-06-16T14:55:19Z

ath.git fixes for 4.7. Major changes: ath9k * fix GPIO mask regression with AR9462 and AR9565 ath10k * fix deadlock while processing rx_in_ord_ind * fix crash related to printing firmware features in debug mode * fix deadlock when peer cannot be created

rtl8xxxu: fix typo on variable name, compare against correct variable

2016-06-16T14:49:18Z

path_b_ok is being assigned but immediately after path_a_ok is being compared to the value 0x03. This appears to be a typo on the variable name, compare path_b_ok instead. Signed-off-by: Colin Ian King Signed-off-by: Jes Sorensen Signed-off-by: Kalle Valo

ath9k: fix GPIO mask for AR9462 and AR9565

2016-06-14T13:21:31Z

The incorrect GPIO mask cause kernel warning, when AR9462 access GPIO11. Also fix the mask for AR9565. WARNING: CPU: 1 PID: 199 at ../drivers/net/wireless/ath/ath9k/hw.c:2778 ath9k_hw_gpio_get+0x1a9/0x1b0 [ath9k_hw] CPU: 1 PID: 199 Comm: kworker/u16:9 Not tainted 4.7.0-rc1-next-20160530+ #5 Hardware name: Acer TravelMate P243/BA40_HC, BIOS V1.01 04/20/2012 Workqueue: events_power_efficient rfkill_poll 0000000000000000 ffff88002cf73d28 ffffffff813b8ddc 0000000000000000 0000000000000000 ffff88002cf73d68 ffffffff8107a331 00000ada00000086 ffff880148d9c018 000000000000000b ffff880147e68720 0000000000000200 Call Trace: [] dump_stack+0x63/0x87 [] __warn+0xd1/0xf0 [] warn_slowpath_null+0x1d/0x20 [] ath9k_hw_gpio_get+0x1a9/0x1b0 [ath9k_hw] [] ath9k_rfkill_poll_state+0x34/0x60 [ath9k] [] ieee80211_rfkill_poll+0x33/0x40 [mac80211] [] cfg80211_rfkill_poll+0x2a/0xc0 [cfg80211] [] rfkill_poll+0x24/0x50 [] process_one_work+0x153/0x3f0 [] worker_thread+0x12b/0x4b0 [] ? rescuer_thread+0x340/0x340 [] kthread+0xc9/0xe0 [] ret_from_fork+0x1f/0x40 [] ? kthread_park+0x60/0x60 Fixes: a01ab81b09c5 ("ath9k: define correct GPIO numbers and bits mask") Reported-by: Sudip Mukherjee Tested-by: Sudip Mukherjee Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo

ath10k: fix deadlock while processing rx_in_ord_ind

2016-06-14T12:06:17Z

commit 5c86d97bcc1d ("ath10k: combine txrx and replenish task") introduced deadlock while processing rx in order indication message for qca6174 based devices. While merging replenish and txrx tasklets, replenish task should be called out of htt rx ring locking since it is also try to acquire the same lock. Unfortunately this issue is not exposed by other solutions (qca988x, qca99x0 & qca4019), as rx_in_ord_ind message is specific to qca6174 based devices. This patch fixes ============================================= [ INFO: possible recursive locking detected ] 4.7.0-rc2-wt-ath+ #1353 Tainted: G E --------------------------------------------- swapper/3/0 is trying to acquire lock: (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [] ath10k_htt_rx_msdu_buff_replenish+0x29/0x90 [ath10k_core] but task is already holding lock: (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [] ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&htt->rx_ring.lock)->rlock); lock(&(&htt->rx_ring.lock)->rlock); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by swapper/3/0: #0: (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [] ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=119151 Fixes: 5c86d97bcc1d ("ath10k: combine txrx and replenish task") Reported-by: Mike Lothian Signed-off-by: Rajkumar Manoharan Signed-off-by: Kalle Valo

iwlwifi: mvm: fix a few firmware capability checks

2016-06-10T11:20:08Z

My cleanup in "iwlwifi: prepare for higher API/CAPA bits" accidentally inverted a few tests - fix them. Fixes: 859d914c8f5c ("iwlwifi: prepare for higher API/CAPA bits") Reported-by: Sara Sharon Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho

iwlwifi: mvm: set the encryption type of an IGTK key

2016-06-10T10:48:12Z

The FW expect the driver to set the encryption algorithm type when installing the IGTK key in the HW. Currently when installing CMAC IGTK key we don't set the algorithm type and as a result the FW fails to calculate the MIC of multicast management frames. Fix it. Signed-off-by: Ayala Beker Signed-off-by: Luca Coelho

iwlwifi: mvm: fix potential NULL-dereference in iwl_mvm_reorder()

2016-06-10T10:34:34Z

We try to access sta before we check for IS_ERR_OR_NULL(), so we may end up accessing a NULL pointer. To prevent that, move the conversion from sta to mvm_sta below the check. Fixes: b915c10174fb ("iwlwifi: mvm: add reorder buffer per queue") Reported-by: Dan Carpenter Signed-off-by: Luca Coelho

iwlwifi: mvm: fix RCU splat in TKIP's update_key

2016-06-10T10:32:25Z

The commit below mistakenly changed an rcu_dereference_check to a rcu_dereference_protected which introduced the following RCU warning: [ INFO: suspicious RCU usage. ] 4.6.0-rc7-next-20160513-dbg-00004-g8de8b92-dirty #655 Not tainted ------------------------------- drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:1069 suspicious rcu_dereference_protected() usage! Call Trace: [] lockdep_rcu_suspicious+0xf7/0x100 [] iwl_mvm_get_key_sta.part.0+0x5d/0x80 [iwlmvm] [] iwl_mvm_update_tkip_key+0xd3/0x162 [iwlmvm] [] iwl_mvm_mac_update_tkip_key+0x17/0x19 [iwlmvm] [] ieee80211_tkip_decrypt_data+0x22c/0x24b [mac80211] [] ieee80211_crypto_tkip_decrypt+0xc5/0x110 [mac80211] [] ieee80211_rx_handlers+0x9bb/0x1fe1 [mac80211] Fixes: 13303c0fb148 ("iwlwifi: mvm: use helpers to get iwl_mvm_sta") Reported-by: Sergey Senozhatsky Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho

iwlwifi: mvm: increase scan timeout to 20 seconds

2016-06-10T09:50:53Z

The 16 seconds timeout we were using turned out to be too short. Recalculations by system show that the total time in both bands should be < 18.5 seconds, even in the slowest cases (e.g. DCM P2P with DTIM=2). Rounding it up to 20 seconds for a bit more safety. Fixes: 728e825f81b1 ("iwlwifi: mvm: add a scan timeout for regular scans") Signed-off-by: Luca Coelho