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

ath9k: fix DMA stop sequence for AR9003+

2015-10-22T01:20:03+00:00

commit 300f77c08ded96d33f492aaa02549103852f0c12 upstream.

AR93xx and newer needs to stop rx before tx to avoid getting the DMA
engine or MAC into a stuck state.
This should reduce/fix the occurence of "Failed to stop Tx DMA" logspam.

Signed-off-by: Felix Fietkau 
Signed-off-by: Kalle Valo 
[lizf: Backported to 3.4:
 - initialize ret
 - ath_drain_all_txq() takes a second argument]
Signed-off-by: Zefan Li

rndis_wlan: harmless issue calling set_bit()

2015-10-22T01:20:02+00:00

commit e3958e9d60b4570fff709f397ef5c6b8483f40f7 upstream.

These are used like:

	set_bit(WORK_LINK_UP, &priv->work_pending);

The problem is that set_bit() takes the actual bit number and not a mask
so static checkers get upset.  It doesn't affect run time because we do
it consistently, but we may as well clean it up.

Fixes: 6010ce07a66c ('rndis_wlan: do link-down state change in worker thread')
Signed-off-by: Dan Carpenter 
Signed-off-by: Kalle Valo 
Signed-off-by: Zefan Li

rtlwifi: rtl8192cu: Fix kernel deadlock

2015-09-18T01:20:37+00:00

commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream.

The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to
usb_control_msg() with a timeout value of 0. In some instances where the
interface is shutting down, this infinite wait results in a CPU deadlock. A
one second timeout fixes this problem without affecting any normal operations.

This bug is reported at https://bugzilla.novell.com/show_bug.cgi?id=927786.

Reported-by: Bernhard Wiedemann 
Tested-by: Bernhard Wiedemann 
Signed-off-by: Larry Finger 
Cc: Bernhard Wiedemann 
Cc: Takashi Iwai
Signed-off-by: Kalle Valo 
Signed-off-by: Zefan Li

rtlwifi: rtl8192cu: Add new USB ID

2015-09-18T01:20:26+00:00

commit 2f92b314f4daff2117847ac5343c54d3d041bf78 upstream.

USB ID 2001:330d is used for a D-Link DWA-131.

Signed-off-by: Larry Finger 
Signed-off-by: Kalle Valo 
Signed-off-by: Zefan Li

ath5k: fix spontaneus AR5312 freezes

2015-06-19T03:40:14+00:00

commit 8bfae4f9938b6c1f033a5159febe97e441d6d526 upstream.

Sometimes while CPU have some load and ath5k doing the wireless
interface reset the whole WiSoC completely freezes. Set of tests shows
that using atomic delay function while we wait interface reset helps to
avoid such freezes.

The easiest way to reproduce this issue: create a station interface,
start continous scan with wpa_supplicant and load CPU by something. Or
just create multiple station interfaces and put them all in continous
scan.

This patch partially reverts the commit 1846ac3dbec0 ("ath5k: Use
usleep_range where possible"), which replaces initial udelay()
by usleep_range().

I do not know actual source of this issue, but all looks like that HW
freeze is caused by transaction on internal SoC bus, while wireless
block is in reset state.

Also I should note that I do not know how many chips are affected, but I
did not see this issue with chips, other than AR5312.

CC: Jiri Slaby 
CC: Nick Kossifidis 
CC: Luis R. Rodriguez 
Fixes: 1846ac3dbec0 ("ath5k: Use usleep_range where possible")
Reported-by: Christophe Prevotaux 
Tested-by: Christophe Prevotaux 
Tested-by: Eric Bree 
Signed-off-by: Sergey Ryazanov 
Signed-off-by: Kalle Valo 
Signed-off-by: Zefan Li

ath5k: fix hardware queue index assignment

2015-04-14T09:33:44+00:00

commit 9e4982f6a51a2442f1bb588fee42521b44b4531c upstream.

Like with ath9k, ath5k queues also need to be ordered by priority.
queue_info->tqi_subtype already contains the correct index, so use it
instead of relying on the order of ath5k_hw_setup_tx_queue calls.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Zefan Li

ath9k: fix BE/BK queue order

2015-04-14T09:33:43+00:00

commit 78063d81d353e10cbdd279c490593113b8fdae1c upstream.

Hardware queues are ordered by priority. Use queue index 0 for BK, which
has lower priority than BE.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Zefan Li

ath9k_hw: fix hardware queue allocation

2015-04-14T09:33:43+00:00

commit ad8fdccf9c197a89e2d2fa78c453283dcc2c343f upstream.

The driver passes the desired hardware queue index for a WMM data queue
in qinfo->tqi_subtype. This was ignored in ath9k_hw_setuptxqueue, which
instead relied on the order in which the function is called.

Reported-by: Hubert Feurstein 
Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Zefan Li

rt2x00: do not align payload on modern H/W

2015-02-02T09:05:21+00:00

commit cfd9167af14eb4ec21517a32911d460083ee3d59 upstream.

RT2800 and newer hardware require padding between header and payload if
header length is not multiple of 4.

For historical reasons we also align payload to to 4 bytes boundary, but
such alignment is not needed on modern H/W.

Patch fixes skb_under_panic problems reported from time to time:

https://bugzilla.kernel.org/show_bug.cgi?id=84911
https://bugzilla.kernel.org/show_bug.cgi?id=72471
http://marc.info/?l=linux-wireless&m=139108549530402&w=2
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087591

Panic happened because we eat 4 bytes of skb headroom on each
(re)transmission when sending frame without the payload and the header
length not being multiple of 4 (i.e. QoS header has 26 bytes). On such
case because paylad_aling=2 is bigger than header_align=0 we increase
header_align by 4 bytes. To prevent that we could change the check to:

	if (payload_length && payload_align > header_align)
		header_align += 4;

but not aligning payload at all is more effective and alignment is not
really needed by H/W (that has been tested on OpenWrt project for few
years now).

Reported-and-tested-by: Antti S. Lankila 
Debugged-by: Antti S. Lankila 
Reported-by: Henrik Asp 
Originally-From: Helmut Schaa 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Zefan Li

wireless: rt2x00: add new rt2800usb device

2015-02-02T09:05:08+00:00

commit 664d6a792785cc677c2091038ce10322c8d04ae1 upstream.

0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle

References: https://bugs.debian.org/766802
Reported-by: Martin Mokrejs 
Signed-off-by: Cyril Brulebois 
Acked-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Zefan Li