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

mwifiex: report error to MMC core if we cannot suspend

2012-12-06T11:20:25+00:00

commit dd321acddc3be1371263b8c9e6c6f2af89f63d57 upstream.

When host_sleep_config command fails we should return error to
MMC core to indicate the failure for our device.

The misspelled variable is also removed as it's redundant.

Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

mwifiex: fix system hang issue in cmd timeout error case

2012-12-06T11:20:24+00:00

commit b1a47aa5e1e159e2cb06d7dfcc17ef5149b09299 upstream.

Reported by Tim Shepard:
I was seeing sporadic failures (wedgeups), and the majority of those
failures I saw printed the printouts in mwifiex_cmd_timeout_func with
cmd = 0xe5 which is CMD_802_11_HS_CFG_ENH.  When this happens, two
minutes later I get notified that the rtcwake thread is blocked, like
this:
      INFO: task rtcwake:3495 blocked for more than 120 seconds.

To get the hung thread unblocked we wake up the cmd wait queue and
cancel the ioctl.

Reported-by: Tim Shepard 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

rtlwifi: rtl8192cu: Add new USB ID

2012-12-06T11:20:24+00:00

commit a485e827f07bfdd0762059386e6e787bed6e81ee upstream.

This is an ISY IWL 2000. Probably a clone of Belkin F7D1102 050d:1102.
Its FCC ID is the same.

Signed-off-by: Albert Pool 
Acked-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

brcm80211: smac: only print block-ack timeout message at trace level

2012-12-06T11:20:16+00:00

commit 2b0a53d51b5f263bb581bbdb40ebb9f7e09609b1 upstream.

In regular use block-ack timeouts can happen so it does not make
sense to fill the log with these messages.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Alwin Beukers 
Signed-off-by: Arend van Spriel 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

ath9k: Test for TID only in BlockAcks while checking tx status

2012-11-16T16:47:01+00:00

commit 6fe7cc71bbf3a0bc28c9cec3c00bc11e81344412 upstream.

The ath9k xmit functions for AMPDUs can send frames as non-aggregate in case
only one frame is currently available. The client will then answer using a
normal Ack instead of a BlockAck. This acknowledgement has no TID stored and
therefore the hardware is not able to provide us the corresponding TID.

The TID set by the hardware in the tx status descriptor has to be seen as
undefined and not as a valid TID value for normal acknowledgements. Doing
otherwise results in a massive amount of retransmissions and stalls of
connections.

Users may experience low bandwidth and complete connection stalls in
environments with transfers using multiple TIDs.

This regression was introduced in b11b160defc48e4daa283f785192ea3a23a51f8e
("ath9k: validate the TID in the tx status information").

Signed-off-by: Sven Eckelmann 
Signed-off-by: Simon Wunderlich 
Acked-by: Felix Fietkau 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

rt2800: validate step value for temperature compensation

2012-11-16T16:47:01+00:00

commit bf7e1abe434ba9e22e8dc04a4cba4ab504b788b8 upstream.

Some hardware has correct (!= 0xff) value of tssi_bounds[4] in the
EEPROM, but step is equal to 0xff. This results on ridiculous delta
calculations and completely broke TX power settings.

Reported-and-tested-by: Pavel Lucik 
Signed-off-by: Stanislaw Gruszka 
Acked-by: Ivo van Doorn 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

ath9k: fix stale pointers potentially causing access to free'd skbs

2012-11-16T16:46:59+00:00

commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.

bf->bf_next is only while buffers are chained as part of an A-MPDU
in the tx queue. When a tid queue is flushed (e.g. on tearing down
an aggregation session), frames can be enqueued again as normal
transmission, without bf_next being cleared. This can lead to the
old pointer being dereferenced again later.

This patch might fix crashes and "Failed to stop TX DMA!" messages.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

Revert "ath9k_hw: Updated AR9003 tx gain table for 5GHz"

2012-10-30T23:26:57+00:00

commit 73b26df5fa1a6245d6fc982362518b620bc7c2fe upstream.

This reverts commit a240dc7b3c7463bd60cf0a9b2a90f52f78aae0fd.

This commit is reducing tx power by at least 10 db on some devices,
e.g. the Buffalo WZR-HP-G450H.

Signed-off-by: Felix Fietkau 
Cc: rmanohar@qca.qualcomm.com
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

iwlwifi: fix 6000 series channel switch command

2012-10-30T23:26:48+00:00

commit 8f7b8db6e0557c8437adf9371e020cd89a7e85dc upstream.

The channel switch command for 6000 series devices
is larger than the maximum inline command size of
320 bytes. The command is therefore refused with a
warning. Fix this by allocating the command and
using the NOCOPY mechanism.

Reviewed-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings

net/wireless: ipw2200: Fix panic occurring in ipw_handle_promiscuous_tx()

2012-10-30T23:26:47+00:00

commit bf11315eeda510ea4fc1a2bf972d8155d31d89b4 upstream.

The driver does not count space of radiotap fields when allocating skb for
radiotap packet. This leads to kernel panic with the following call trace:

...
[67607.676067] [] error_code+0x67/0x6c
[67607.676067] [] ? skb_put+0x91/0xa0
[67607.676067] [] ? ipw_handle_promiscuous_tx+0x16b/0x2d0 [ipw2200]
[67607.676067] [] ipw_handle_promiscuous_tx+0x16b/0x2d0 [ipw2200]
[67607.676067] [] ipw_net_hard_start_xmit+0x8b/0x90 [ipw2200]
[67607.676067] [] libipw_xmit+0x55a/0x980 [libipw]
[67607.676067] [] dev_hard_start_xmit+0x218/0x4d0
...

This bug was found by VittGam.
https://bugzilla.kernel.org/show_bug.cgi?id=43255

Signed-off-by: Stanislav Yakovlev 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings