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

iwlwifi: dvm: don't override mac80211's queue setting

2013-12-12T06:37:55+00:00

commit f6b129527ca15bae29ffb9417ddaa1c9d99ffc5d upstream.

Since we set IEEE80211_HW_QUEUE_CONTROL, we can let
mac80211 do the queue assignement and don't need to
override its decisions.
While reassiging the same values is harmless of course,
it triggered  a WARNING when iwlwifi and mac80211 came
to different conclusions. This happened when mac80211 set
IEEE80211_TX_CTL_SEND_AFTER_DTIM, but didn't route the
packet to the cab_queue because no stations were asleep.

iwlwifi should not override mac80211's decicions for
offchannel packets and packets to  be sent after DTIM,
but it should override mac80211's decision for AMPDUs
since we have a special queue for them. So for AMPDU,
we still override info->hw_queue by the AMPDU queue.

This avoids:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 2531 at drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x6c5/0x883()
Modules linked in:
CPU: 0 PID: 2531 Comm: hostapd Not tainted 3.12.0-rc5+ #1
Hardware name:                  /D53427RKE, BIOS RKPPT10H.86A.0017.2013.0425.1251 04/25/2013
 0000000000000000 0000000000000009 ffffffff8189aa62 0000000000000000
 ffffffff8105a4f2 ffff880058339a48 ffffffff815f8a04 0000000000000000
 ffff8800560097b0 0000000000000208 0000000000000000 ffff8800561a9e5e
Call Trace:
 [] ? dump_stack+0x41/0x51
 [] ? warn_slowpath_common+0x78/0x90
 [] ? iwlagn_tx_skb+0x6c5/0x883
 [] ? iwlagn_tx_skb+0x6c5/0x883
 [] ? put_cred+0x15/0x15
 [] ? iwlagn_mac_tx+0x19/0x2f
 [] ? __ieee80211_tx+0x226/0x29b
 [] ? ieee80211_tx+0xa6/0xb5
 [] ? ieee80211_monitor_start_xmit+0x1e9/0x204
 [] ? dev_hard_start_xmit+0x271/0x3ec
 [] ? sch_direct_xmit+0x66/0x164
 [] ? dev_queue_xmit+0x1e5/0x3c8
 [] ? packet_sendmsg+0xac5/0xb3d
 [] ? sock_sendmsg+0x37/0x52
 [] ? __do_fault+0x338/0x36b
 [] ? verify_iovec+0x44/0x94
 [] ? ___sys_sendmsg+0x1f1/0x283
 [] ? __inode_wait_for_writeback+0x67/0xae
 [] ? __cache_free.isra.46+0x178/0x187
 [] ? kmem_cache_free+0x44/0x84
 [] ? dentry_kill+0x13d/0x149
 [] ? dput+0xe5/0xef
 [] ? fget_light+0x2e/0x7c
 [] ? __sys_sendmsg+0x39/0x57
 [] ? system_call_fastpath+0x16/0x1b
---[ end trace 1b3eb79359c1d1e6 ]---

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

rt2800: add support for radio chip RF3070

2013-12-08T15:29:16+00:00

commit 3b9b74baa1af2952d719735b4a4a34706a593948 upstream.

Add support for new RF chip ID: 3070. It seems to be the same as 5370,
maybe vendor just put wrong value on the eeprom, but add this id anyway
since devices with it showed on the marked.

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

prism54: set netdev type to "wlan"

2013-12-04T19:05:41+00:00

commit 8e3ffa471091c560deb6738ed9ab7445b7a5fd04 upstream.

Userspace uses the netdev devtype for stuff like device naming and type
detection.  Be nice and set it.  Remove the pointless #if/#endif around
SET_NETDEV_DEV too.

Signed-off-by: Dan Williams 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mwifiex: fix wrong eth_hdr usage for bridged packets in AP mode

2013-12-04T19:05:39+00:00

commit 8d93f1f309d38b65fce0b9f0de91ba6c96990c07 upstream.

The eth_hdr is never defined in this driver but it gets compiled
without any warning/error because kernel has defined eth_hdr.

Fix it by defining our own p_ethhdr and use it instead of eth_hdr.

Signed-off-by: Ujjal Roy 
Signed-off-by: Amitkumar Karwar 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mwifiex: correct packet length for packets from SDIO interface

2013-12-04T19:05:38+00:00

commit d03b4aa77e1187b77dfe37d14a923547f00baa66 upstream.

While receiving a packet on SDIO interface, we allocate skb with
size multiple of SDIO block size. We need to resize this skb
after RX using packet length from RX header.

Signed-off-by: Avinash Patil 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rt2400pci: fix RSSI read

2013-12-04T19:05:26+00:00

commit 2bf127a5cc372b9319afcbae10b090663b621c8b upstream.

RSSI value is provided on word3 not on word2.

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath5k: fix regression in tx status processing

2013-12-04T19:05:26+00:00

commit 7ede612fd615abcda0cc30e5bef2a70f4cf4f75c upstream.

The regression was introduced in the following commit:

0967e01e8e713ed2982fb4eba8ba13794e9a6e89
"ath5k: make use of the new rate control API"

ath5k_tx_frame_completed saves the intended per-rate retry counts before
they are cleared by ieee80211_tx_info_clear_status, however at this
point the information in info->status.rates is incomplete.

This causes significant throughput degradation and excessive packet loss
on links where high bit rates don't work properly.

Move the copy from bf->rates a few lines up to ensure that the saved
retry counts are updated, and that they are really cleared in
info->status.rates after the call to ieee80211_tx_info_clear_status.

Cc: Thomas Huehn 
Cc: Benjamin Vahl 
Reported-by: Ben West 
Signed-off-by: Felix Fietkau 
Acked-by: Thomas Huehn 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: rtl8192cu: Fix incorrect signal strength for unassociated AP

2013-12-04T19:05:26+00:00

commit 78dbfecb95be4635b995af3bd29fa10013409fcd upstream.

The routine that processes received frames was returning the RSSI value for the
signal strength; however, that value is available only for associated APs. As
a result, the strength was the absurd value of 10 dBm. As a result, scans
return incorrect values for the strength, which causes unwanted attempts to roam.

Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: rtl8192se: Fix incorrect signal strength for unassociated AP

2013-12-04T19:05:26+00:00

commit b4ade797668e33b4e8353c2701ce01d7084dfafa upstream.

The routine that processes received frames was returning the RSSI value for the
signal strength; however, that value is available only for associated APs. As
a result, the strength was the absurd value of 10 dBm. As a result, scans
return incorrect values for the strength, which causes unwanted attempts to roam.

This patch fixes https://bugzilla.kernel.org/show_bug.cgi?id=63881.

Signed-off-by: Larry Finger 
Reported-by: Matthieu Baerts 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: rtl8192de: Fix incorrect signal strength for unassociated AP

2013-12-04T19:05:26+00:00

commit 3545f3d5f4af715c914394123ce7725a9cf0a1c4 upstream.

The routine that processes received frames was returning the RSSI value for the
signal strength; however, that value is available only for associated APs. As
a result, the strength was the absurd value of 10 dBm. As a result, scans
return incorrect values for the strength, which causes unwanted attempts to roam.

Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman