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

iwlwifi: mvm: Add a missed beacons threshold

2014-08-26T12:12:02+00:00

commit 12d423e816c69b0b4457bc047dda9a0a1c1a53c1 upstream.

Instead of always calling ieee80211_beacon_loss() on every missed
beacons notification, call this function only if the number of
consecutive missed beacons from last rx is higher than a predefined
threshold.

Signed-off-by: Ilan Peer 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Jiri Slaby

ath9k: fix aggregation session lockup

2014-08-19T12:23:34+00:00

commit c01fac1c77a00227f706a1654317023e3f4ac7f0 upstream.

If an aggregation session fails, frames still end up in the driver queue
with IEEE80211_TX_CTL_AMPDU set.
This causes tx for the affected station/tid to stall, since
ath_tx_get_tid_subframe returning packets to send.

Fix this by clearing IEEE80211_TX_CTL_AMPDU as long as no aggregation
session is running.

Reported-by: Antonio Quartulli 
Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Jiri Slaby

mwifiex: fix Tx timeout issue

2014-07-29T15:01:42+00:00

commit d76744a93246eccdca1106037e8ee29debf48277 upstream.

https://bugzilla.kernel.org/show_bug.cgi?id=70191
https://bugzilla.kernel.org/show_bug.cgi?id=77581

It is observed that sometimes Tx packet is downloaded without
adding driver's txpd header. This results in firmware parsing
garbage data as packet length. Sometimes firmware is unable
to read the packet if length comes out as invalid. This stops
further traffic and timeout occurs.

The root cause is uninitialized fields in tx_info(skb->cb) of
packet used to get garbage values. In this case if
MWIFIEX_BUF_FLAG_REQUEUED_PKT flag is mistakenly set, txpd
header was skipped. This patch makes sure that tx_info is
correctly initialized to fix the problem.

Reported-by: Andrew Wiley 
Reported-by: Linus Gasser 
Reported-by: Michael Hirsch 
Tested-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
Signed-off-by: Maithili Hinge 
Signed-off-by: Avinash Patil 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville 
Signed-off-by: Jiri Slaby

iwlwifi: dvm: don't enable CTS to self

2014-07-29T14:56:55+00:00

commit 43d826ca5979927131685cc2092c7ce862cb91cd upstream.

We should always prefer to use full RTS protection. Using
CTS to self gives a meaningless improvement, but this flow
is much harder for the firmware which is likely to have
issues with it.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Jiri Slaby

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

2014-07-18T13:51:03+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: Jiri Slaby

iwlwifi: pcie: try to get ownership several times

2014-07-17T13:04:38+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: Jiri Slaby

rt2x00: fix rfkill regression on rt2500pci

2014-07-17T13:04:36+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: Jiri Slaby

rt2x00: disable TKIP on USB

2014-07-17T13:04:35+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: Jiri Slaby

rtlwifi: rtl8192se: Fix regression due to commit 1bf4bbb

2014-06-18T09:17:31+00:00

commit 5f9186990ec4579ee5b7a99b3254c29eda479f36 upstream.

Beginning with kernel 3.13, this driver fails on some systems. The problem
was bisected to:

Commit 1bf4bbb4024dcdab5e57634dd8ae1072d42a53ac
Author: Felix Fietkau 
Title: mac80211: send control port protocol frames to the VO queue

There is noting wrong with the above commit. The regression occurs because
V0 queue on RTL8192SE cards uses priority 6, not the usual 7. The fix is to
modify the rtl8192se routine that sets the correct transmit queue.

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

Reported-by: Alex Miller 
Tested-by: Alex Miller 
Signed-off-by: Larry Finger 
Cc: Stable     [3.13+]
Signed-off-by: John W. Linville 
Signed-off-by: Jiri Slaby

ath9k: Fix sequence number assignment for non-data frames

2014-06-18T09:16:15+00:00

commit 5998be879719384af2014b79697eed6e38ee2706 upstream.

Since commit 558ff225de80ac95b132d3a115ddadcd64498b4f (ath9k: fix
ps-poll responses under a-mpdu sessions) non-data frames would have
gotten a sequence number from a TIDs sequence counter instead of
using the global sequence counter.

This can lead to instable connections.

To fix this only select the correct TID if we are processing a
data frame. Furthermore, prevent non-data frames to get a sequence
number from a TID sequence counter by adding a check to
ath_tx_setup_buffer.

Cc: Felix Fietkau 
Signed-off-by: Helmut Schaa 
Acked-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Jiri Slaby