linux-stable.git/drivers/net/wireless, branch v3.14.7

iwlwifi: mvm: rs: clear per rate stats when aggregation changes

2014-06-07T17:28:28+00:00

commit b804eeb6649d75caeccbeae9f5623fc7b8bdfdfa upstream.

The per rate stats should be cleared when aggregation state changes
to avoid making rate scale decisions based on throughput figures which
were collected prior to the aggregation state change and are now stale.
While at it make sure any clearing of the per rate stats will get logged.

Signed-off-by: Eyal Shapira 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: add rs_rate_scale_clear_tbl_windows helper function

2014-06-07T17:28:28+00:00

commit 3ca71f603bb1a0f55e1ba24618ba45617bc36f70 upstream.

instead of duplicating the same loop multiple times,
use a new function for it.

this will be later used also for clearing other
windows in the table.

Signed-off-by: Eliad Peller 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: disable beacon filtering

2014-06-07T17:28:28+00:00

commit 7bacc782270ff7db3b9f29fa5d24ad2ee1e8e81d upstream.

This feature has been causing trouble - disable it for now.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: BT Coex - fix Look Up Table

2014-06-07T17:28:25+00:00

commit a6bc92803e7f765e02c923cf37c8e280e729642a upstream.

A few entries were wrong and this caused throughput issues.

Fixes: dac94da8dba3 ("iwlwifi: mvm: new BT Coex API")
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: fix setting channel in monitor mode

2014-06-07T17:28:23+00:00

commit 1c4abec0baf25ffb92a28cc99d4231feeaa4d3f3 upstream.

There was a deadlock in monitor mode when we were setting the
channel if the channel was not 1.

======================================================
[ INFO: possible circular locking dependency detected ]
3.14.3 #4 Not tainted
-------------------------------------------------------
iw/3323 is trying to acquire lock:
 (&local->chanctx_mtx){+.+.+.}, at: [] ieee80211_vif_release_channel+0x42/0xb0 [mac80211]

but task is already holding lock:
 (&local->iflist_mtx){+.+...}, at: [] ieee80211_set_monitor_channel+0x5a/0x1b0 [mac80211]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&local->iflist_mtx){+.+...}:
       [] __lock_acquire+0xb3b/0x13b0
       [] lock_acquire+0xb0/0x1f0
       [] mutex_lock_nested+0x78/0x4f0
       [] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
       [] iwl_mvm_recalc_multicast+0x49/0xa0 [iwlmvm]
       [] iwl_mvm_configure_filter+0x4e/0x70 [iwlmvm]
       [] ieee80211_configure_filter+0x153/0x5f0 [mac80211]
       [] ieee80211_reconfig_filter+0x15/0x20 [mac80211]
       [snip]

-> #1 (&mvm->mutex){+.+.+.}:
       [] __lock_acquire+0xb3b/0x13b0
       [] lock_acquire+0xb0/0x1f0
       [] mutex_lock_nested+0x78/0x4f0
       [] iwl_mvm_add_chanctx+0x56/0xe0 [iwlmvm]
       [] ieee80211_new_chanctx+0x13e/0x410 [mac80211]
       [] ieee80211_vif_use_channel+0x1c3/0x5a0 [mac80211]
       [] ieee80211_add_virtual_monitor+0x1ab/0x6b0 [mac80211]
       [] ieee80211_do_open+0xe6a/0x15a0 [mac80211]
       [] ieee80211_open+0x59/0x60 [mac80211]
       [snip]

-> #0 (&local->chanctx_mtx){+.+.+.}:
       [] check_prevs_add+0x977/0x980
       [] __lock_acquire+0xb3b/0x13b0
       [] lock_acquire+0xb0/0x1f0
       [] mutex_lock_nested+0x78/0x4f0
       [] ieee80211_vif_release_channel+0x42/0xb0 [mac80211]
       [] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211]
       [] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211]
       [] __nl80211_set_channel+0x122/0x140 [cfg80211]
       [] nl80211_set_wiphy+0x284/0xaf0 [cfg80211]
       [snip]

other info that might help us debug this:

Chain exists of:
  &local->chanctx_mtx --> &mvm->mutex --> &local->iflist_mtx

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&local->iflist_mtx);
                               lock(&mvm->mutex);
                               lock(&local->iflist_mtx);
  lock(&local->chanctx_mtx);

 *** DEADLOCK ***

This deadlock actually occurs:
INFO: task iw:3323 blocked for more than 120 seconds.
      Not tainted 3.14.3 #4
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
iw              D ffff8800c8afcd80  4192  3323   3322 0x00000000
 ffff880078fdb7e0 0000000000000046 ffff8800c8afcd80 ffff880078fdbfd8
 00000000001d5540 00000000001d5540 ffff8801141b0000 ffff8800c8afcd80
 ffff880078ff9e38 ffff880078ff9e38 ffff880078ff9e40 0000000000000246
Call Trace:
 [] schedule_preempt_disabled+0x31/0x80
 [] mutex_lock_nested+0x19d/0x4f0
 [] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
 [] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
 [] ? iwl_mvm_power_mac_update_mode+0xc0/0xc0 [iwlmvm]
 [] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
 [] _iwl_mvm_power_update_binding+0x27/0x80 [iwlmvm]
 [] iwl_mvm_unassign_vif_chanctx+0x81/0xc0 [iwlmvm]
 [] __ieee80211_vif_release_channel+0xdf/0x470 [mac80211]
 [] ieee80211_vif_release_channel+0x4a/0xb0 [mac80211]
 [] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211]
 [] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211]
 [] __nl80211_set_channel+0x122/0x140 [cfg80211]
 [] nl80211_set_wiphy+0x284/0xaf0 [cfg80211]

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=75541

Reviewed-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: disable interrupts upon PCIe alloc

2014-06-07T17:28:22+00:00

commit 83f7a85f1134c6e914453f5747435415a23d516b upstream.

In case RFKILL is in KILL position, the NIC will issue an
interrupt straight away. This interrupt won't be sent
because it is masked in the hardware.
But if our interrupt service routine is called for another
reason (SHARED_IRQ), then we'll look at the interrupt cause
and service it. This can cause bad things if we are not
ready yet.
Explicitly clean the interrupt cause register to make sure
we won't service anything before we are ready to.

Reported-and-tested-by: Alexander Monakov 
Reviewed-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

brcmsmac: fix deadlock on missing firmware

2014-06-07T17:28:18+00:00

commit 8fc1e8c240aab968db658b2d8d079b4391207a36 upstream.

When brcm80211 firmware is not installed networking hangs.
A deadlock happens because we call ieee80211_unregister_hw()
from the .start callback of struct ieee80211_ops. When .start
is called we are under rtnl lock and ieee80211_unregister_hw()
tries to take it again.

Function call stack:

dev_change_flags()
	__dev_change_flags()
		__dev_open()
			ASSERT_RTNL() <-- Assert rtnl lock
			ops->ndo_open()

.ndo_open = ieee80211_open,

ieee80211_open()
	ieee80211_do_open()
		drv_start()
			local->ops->start()

.start = brcms_ops_start,

brcms_ops_start()
	brcms_remove()
		ieee80211_unregister_hw()
			rtnl_lock() <-- Here we deadlock

Introduced by:
commit 25b5632fb35ca61b8ae3eee235edcdc2883f7a5e
("brcmsmac: request firmware in .start() callback")

This patch fixes the bug by removing the call to brcms_remove()
and moves the brcms_request_fw() call to the top of the .start
callback to not initiate anything unless firmware is installed.

Signed-off-by: Emil Goode 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtl8192cu: Fix unbalanced irq enable in error path of rtl92cu_hw_init()

2014-06-07T17:28:18+00:00

commit 3234f5b06fc3094176a86772cc64baf3decc98fc upstream.

Fixes: a53268be0cb9 ('rtlwifi: rtl8192cu: Fix too long disable of IRQs')
Signed-off-by: Ben Hutchings 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rt2x00: fix beaconing on USB

2014-06-07T17:28:16+00:00

commit 8834d3608cc516f13e2e510f4057c263f3d2ce42 upstream.

When disable beaconing we clear register with beacon and newer set it
back, what make we stop send beacons infinitely.

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: delay enabling smart FIFO until after beacon RX

2014-06-07T17:28:11+00:00

commit 0229cdafb6f67064a217591d48b0f6abf14e8385 upstream.

If we have no beacon data before association, delay smart FIFO
enablement until after we have this data.

Not doing so can cause association failures in extremely silent
environments (usually only a shielded box/room) as beacon RX is
not sent to the host immediately, and then the association time
event ends without the host receiving any beacon even though it
was on the air - it's just stuck on the FIFO.

Fixes: 1f3b0ff8ecce ("iwlwifi: mvm: Add Smart FIFO support")
Signed-off-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman