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

rtlwifi: rtl8192ee: Fix handling of new style descriptors

2015-04-29T08:23:47+00:00

commit d0311314d00298f83aa5450a1d4a92889e7cc2ea upstream.

The hardware and firmware for the RTL8192EE utilize a FIFO list of
descriptors. There were some problems with the initial implementation.
The worst of these failed to detect that the FIFO was becoming full,
which led to the device needing to be power cycled. As this condition
is not relevant to most of the devices supported by rtlwifi, a callback
routine was added to detect this situation. This patch implements the
necessary changes in the pci handler, and the linkage into the appropriate
rtl8192ee routine.

Signed-off-by: Troy Tan 
Signed-off-by: Larry Finger 
Cc: Stable  [V3.18]
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: Fix IOMMU mapping leak in AP mode

2015-04-19T08:10:23+00:00

commit be0b5e635883678bfbc695889772fed545f3427d upstream.

Transmission of an AP beacon does not call the TX interrupt service routine,
which usually does the cleanup. Instead, cleanup is handled in a tasklet
completion routine. Unfortunately, this routine has a serious bug in that it does
not release the DMA mapping before it frees the skb, thus one IOMMU mapping is
leaked for each beacon. The test system failed with no free IOMMU mapping slots
approximately one hour after hostapd was used to start an AP.

This issue was reported and tested at https://github.com/lwfinger/rtlwifi_new/issues/30.

Reported-and-tested-by: Kevin Mullican 
Cc: Kevin Mullican 
Signed-off-by: Shao Fu 
Signed-off-by: Larry Finger 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: disable MBSS feature for BCM43362

2015-04-19T08:10:23+00:00

commit f93a25b38cbd840f26c9fd2dd8a6611a57b259b7 upstream.

The BCM43362 firmware falsely reports it is capable of providing
MBSS. As a result AP mode no longer works for this device. Therefor
disable MBSS in the driver for this chipset.

Reported-by: Jorg Krause 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath9k: fix tracking of enabled AP beacons

2015-04-19T08:10:20+00:00

commit 1cf48f22c98ae24a49a3f1b6900e4c9a9a0fcc62 upstream.

sc->nbcnvifs tracks assigned beacon slots, not enabled beacons.
Therefore, it cannot be used to decide if cur_conf->enable_beacon (bool)
should be updated, or if beacons have been enabled already.
With the current code (depending on the order of calls), beacons often
do not get enabled in an AP+STA setup.
To fix tracking of enabled beacons, convert cur_conf->enable_beacon to a
bitmask of enabled beacon slots.

Signed-off-by: Felix Fietkau 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: dvm: run INIT firmware again upon .start()

2015-04-19T08:10:16+00:00

commit 9c8928f5176766bec79f272bd47b7124e11cccbd upstream.

The assumption before this patch was that we don't need to
run again the INIT firmware after the system booted. The
INIT firmware runs calibrations which impact the physical
layer's behavior.
Users reported that it may be helpful to run these
calibrations again every time the interface is brought up.
The penatly is minimal, since the calibrations run fast.
This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=94341

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

brcmfmac: Perform bound checking on vendor command buffer

2015-04-13T12:03:54+00:00

commit 3f1615340acea54e21f4b9d4d65921540dca84b2 upstream.

A short or malformed vendor command buffer could cause reads outside
the command buffer.

Signed-off-by: Pontus Fuchs 
[arend@broadcom.com: slightly modified debug trace output]
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: Improve handling of IPv6 packets

2015-04-13T12:03:53+00:00

commit c8f0345586694a33f828bc6b177fb21eb1702325 upstream.

Routine rtl_is_special_data() is supposed to identify packets that need to
use a low bit rate so that the probability of successful transmission is
high. The current version has a bug that causes all IPv6 packets to be
labelled as special, with a corresponding low rate of transmission. A
complete fix will be quite intrusive, but until that is available, all
IPv6 packets are identified as regular.

This patch also removes a magic number.

Reported-and-tested-by: Alan Fisher 
Signed-off-by: Larry Finger 
Cc: Alan Fisher 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: Fix ROC removal

2015-04-13T12:03:53+00:00

commit 833d9b9785b3eedfaf2c869a6a63deba88058599 upstream.

iwl_mvm_stop_roc removes TE only if running flag is set. This is not correct
since this flag is only set when the TE is started.
This resulted in a TE not being removed, when mac80211 believes that there are
no active ROCs.

Fixes: bf5da87f60a9 ("iwlwifi: mvm: add remove flow for AUX ROC time events")
Signed-off-by: Andrei Otcheretianski 
Reviewed-by: Matti Gottlieb 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: BT Coex - fix a NULL pointer exception

2015-04-13T12:03:53+00:00

commit 4cd4b50cc2429294c23a1998c33fdfd804db0f37 upstream.

The commit below introduced an unsafe dereference of
mvmvif->phy_ctxt. It can be NULL even if we hold the mutex.
We can be handling a BT Coex notification while the vif has
already been unassigned. This can happen since the BT Coex
notification is hanled asynchronuously: we can have started
to handle the BT Coex notification trying to acquire the
mutex while the unassign flow already got it. The BT Coex
notification handling will wait for the mutext. I'll get it
later, but then mvmvif->phy_ctxt will be NULL.

Panic log:

BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [] iwl_mvm_bt_notif_iterator+0x9d/0x340 [iwlmvm]
*pdpt = 0000000000000000 *pde = f000eef300000007
Oops: 0000 [#1] SMP
Workqueue: events iwl_mvm_async_handlers_wk [iwlmvm]
task: ed719b20 ti: ec03e000 task.ti: ec03e000
EIP: 0060:[] EFLAGS: 00010202 CPU: 2
EIP is at iwl_mvm_bt_notif_iterator+0x9d/0x340 [iwlmvm]
EAX: 00000000 EBX: f6d3cb70 ECX: f6d3cb70 EDX: 00000000
ESI: ec03fe40 EDI: efeb8810 EBP: ec03fdf0 ESP: ec03fdac
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 80050033 CR2: 00000000 CR3: 01a1a000 CR4: 001407f0
Stack:
 f743ca80 f744a404 ec03fdcc c10e3952 00003aba f743ca80 00000246 f743ca80
 00000246 00000000 00000001 00000000 ebd45ff6 ebd458a4 f6d3c500 ebd45578
 ebd44b01 ec03fe18 f99e1bc2 00000002 ebd44bc0 f9851770 00000000 f6d3c500
Call Trace:
 [] ? ring_buffer_unlock_commit+0xa2/0xd0
 [] __iterate_interfaces+0x82/0x110 [mac80211]
 [] ? iwl_mvm_bt_coex_reduced_txp+0x140/0x140 [iwlmvm]
 [] ieee80211_iterate_active_interfaces_atomic+0x1a/0x20 [mac80211]
 [] iwl_mvm_bt_coex_notif_handle+0x77/0x280 [iwlmvm]
 [] iwl_mvm_rx_bt_coex_notif_old+0x211/0x220 [iwlmvm]
 [] iwl_mvm_rx_bt_coex_notif+0x19b/0x1b0 [iwlmvm]
 [] iwl_mvm_async_handlers_wk+0x7f/0xe0 [iwlmvm]

Fixes: 123f515635b1 ("iwlwifi: mvm: BT Coex - add support for TTC / RRC")
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: fix max_ht_ampdu_exponent for older devices

2015-04-13T12:03:52+00:00

commit 540623caa6c769d9d19e6044949f5fa2fe1a33a6 upstream.

The commit below didn't update the max_ht_ampdu_exponent
for the devices listed in iwl-[1-6]000.c which, in result,
became 0 instead of 8K. This reduced the size of the Rx
AMPDU from 64K to 8K which had an impact in the Rx
throughput. One user reported that because of this, his
downstream throughput droppped by a half.

Fixes: c064ddf318aa ("iwlwifi: change max HT and VHT A-MPDU exponent")
Reported-and-tested-by: Valentin Manea 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman