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

brcmfmac: Fix brcmf_chip_ai_coredisable not applying reset bits to BCMA_IOCTL

2014-07-09T18:18:28+00:00

commit ffa216bb5eecfce0f01b0b2a95d5c320dde90005 upstream.

brcmfmac has been broken on my cubietruck with a BCM43362:

brcmfmac: brcmf_chip_recognition: found AXI chip: BCM43362, rev=1
brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
        Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d

since commit 53036261033: "brcmfmac: update core reset and disable routines".

The problem is that since this commit brcmf_chip_ai_resetcore no longer sets
BCMA_IOCTL itself before bringing the core out of reset, instead relying on
brcmf_chip_ai_coredisable to do so. But brcmf_chip_ai_coredisable is a nop
of the chip is already in reset. This patch modifies brcmf_chip_ai_coredisable
to always set BCMA_IOCTL even if the core is already in reset.

This fixes brcmfmac hanging in firmware loading on my board.

Cc: stable@vger.kernel.org # v3.14
Signed-off-by: Hans de Goede 
Acked-by: Arend van Spriel 
Signed-off-by: John W. Linville 
[arend@broadcom.com: rebase patch on linux-3.14.y branch]
Signed-off-by: Arend van Spriel 
Signed-off-by: Greg Kroah-Hartman

b43: fix frequency reported on G-PHY with /new/ firmware

2014-07-09T18:18:27+00:00

commit 2fc68eb122c7ea6cd5be1fe7d6650c0beb2f4f40 upstream.

Support for firmware rev 508+ was added years ago, but we never noticed
it reports channel in a different way for G-PHY devices. Instead of
offset from 2400 MHz it simply passes channel id (AKA hw_value).

So far it was (most probably) affecting monitor mode users only, but
the following recent commit made it noticeable for quite everybody:

commit 3afc2167f60a327a2c1e1e2600ef209a3c2b75b7
Author: Emmanuel Grumbach 
Date:   Tue Mar 4 16:50:13 2014 +0200

    cfg80211/mac80211: ignore signal if the frame was heard on wrong channel

Reported-by: Aaro Koskinen 
Signed-off-by: Rafał Miłecki 
Tested-by: Aaro Koskinen 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: try to get ownership several times

2014-07-09T18:18:26+00:00

commit 501fd9895c1d7d8161ed56698ae2fccb10ef14f5 upstream.

Some races with the hardware can happen when we take
ownership of the device. Don't give up after the first try.

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

rt2x00: fix rfkill regression on rt2500pci

2014-07-09T18:18:24+00:00

commit 616a8394b5df8c88f4dd416f4527439a4e365034 upstream.

As reported by Niels, starting rfkill polling during device probe
(commit e2bc7c5, generally sane change) broke rfkill on rt2500pci
device. I considered that bug as some initalization issue, which
should be fixed on rt2500pci specific code. But after several
attempts (see bug report for details) we fail to find working solution.
Hence I decided to revert to old behaviour on rt2500pci to fix
regression.

Additionally patch also unregister rfkill on device remove instead
of ifconfig down, what was another issue introduced by bad commit.

Bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=73821

Fixes: e2bc7c5f3cb8 ("rt2x00: Fix rfkill_polling register function.")
Bisected-by: Niels 
Reported-and-tested-by: Niels 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rt2x00: disable TKIP on USB

2014-07-09T18:18:24+00:00

commit 8edcb0ba0d56f5914eef11eda6db8bfe74eb9ca8 upstream.

On USB we can not get atomically TKIP key. We have to disable support
for TKIP acceleration on USB hardware to avoid bug as showed bellow.

[  860.827243] BUG: scheduling while atomic: hostapd/3397/0x00000002

[  860.827280] Call Trace:
[  860.827282]  [] dump_stack+0x4d/0x66
[  860.827284]  [] __schedule_bug+0x47/0x55
[  860.827285]  [] __schedule+0x733/0x7b0
[  860.827287]  [] schedule+0x29/0x70
[  860.827289]  [] schedule_timeout+0x15a/0x2b0
[  860.827291]  [] ? ftrace_raw_event_tick_stop+0xc0/0xc0
[  860.827294]  [] ? __module_text_address+0x12/0x70
[  860.827296]  [] wait_for_completion_timeout+0xb3/0x140
[  860.827298]  [] ? wake_up_state+0x20/0x20
[  860.827301]  [] usb_start_wait_urb+0x7d/0x150
[  860.827303]  [] usb_control_msg+0xc5/0x110
[  860.827305]  [] rt2x00usb_vendor_request+0xc6/0x160  [rt2x00usb]
[  860.827307]  [] rt2x00usb_vendor_req_buff_lock+0x75/0x150 [rt2x00usb]
[  860.827309]  [] rt2x00usb_vendor_request_buff+0xa3/0xe0 [rt2x00usb]
[  860.827311]  [] rt2x00usb_register_multiread+0x33/0x40 [rt2800usb]
[  860.827314]  [] rt2800_get_tkip_seq+0x39/0x50  [rt2800lib]
[  860.827321]  [] ieee80211_get_key+0x218/0x2a0  [mac80211]
[  860.827322]  [] ? __nlmsg_put+0x6c/0x80
[  860.827329]  [] nl80211_get_key+0x22e/0x360 [cfg80211]

Reported-and-tested-by: Peter Wu 
Reported-and-tested-by: Pontus Fuchs 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

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