linux-stable.git/drivers/net, branch v3.17.3

Revert "iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate"

2014-11-14T18:10:37+00:00

commit 1ffde699aae127e7abdb98dbdedc2cc6a973a1a1 upstream.

This reverts commit aa11bbf3df026d6b1c6b528bef634fd9de7c2619.
This commit was causing connection issues and is not needed
if IWL_MVM_RS_RSSI_BASED_INIT_RATE is set to false by default.

Regardless of the issues mentioned above, this patch added the
following WARNING:

WARNING: CPU: 0 PID: 3946 at drivers/net/wireless/iwlwifi/mvm/tx.c:190 iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]()
Got an HT rate for a non data frame 0x8
CPU: 0 PID: 3946 Comm: wpa_supplicant Tainted: G           O   3.17.0+ #6
Hardware name: LENOVO 20ANCTO1WW/20ANCTO1WW, BIOS GLET71WW (2.25 ) 07/02/2014
 0000000000000009 ffffffff814fa911 ffff8804288db8f8 ffffffff81064f52
 0000000000001808 ffff8804288db948 ffff88040add8660 ffff8804291b5600
 0000000000000000 ffffffff81064fb7 ffffffffa07b73d0 0000000000000020
Call Trace:
 [] ? dump_stack+0x41/0x51
 [] ? warn_slowpath_common+0x72/0x90
 [] ? warn_slowpath_fmt+0x47/0x50
 [] ? iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]
 [] ? iwl_mvm_tx_skb+0x48/0x3c0 [iwlmvm]
 [] ? iwl_mvm_mac_tx+0x7b/0x180 [iwlmvm]
 [] ? __ieee80211_tx+0x2b9/0x3c0 [mac80211]
 [] ? ieee80211_tx+0xb3/0x100 [mac80211]
 [] ? ieee80211_subif_start_xmit+0x459/0xca0 [mac80211]
 [] ? dev_hard_start_xmit+0x337/0x5f0
 [] ? sch_direct_xmit+0x96/0x1f0
 [] ? __dev_queue_xmit+0x203/0x4f0
 [] ? ether_setup+0x70/0x70
 [] ? packet_sendmsg+0xf81/0x1110
 [] ? skb_free_datagram+0xc/0x40
 [] ? sock_sendmsg+0x88/0xc0
 [] ? move_addr_to_kernel.part.20+0x14/0x60
 [] ? __inode_wait_for_writeback+0x62/0xb0
 [] ? SYSC_sendto+0xf1/0x180
 [] ? __sys_recvmsg+0x39/0x70
 [] ? system_call_fastpath+0x1a/0x1f
---[ end trace cc19a150d311fc63 ]---

which was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=85691

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

iwlwifi: dvm: drop non VO frames when flushing

2014-11-14T18:10:37+00:00

commit a0855054e59b0c5b2b00237fdb5147f7bcc18efb upstream.

When mac80211 wants to ensure that a frame is sent, it calls
the flush() callback. Until now, iwldvm implemented this by
waiting that all the frames are sent (ACKed or timeout).
In case of weak signal, this can take a significant amount
of time, delaying the next connection (in case of roaming).
Many users have reported that the flush would take too long
leading to the following error messages to be printed:

iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 2
iwlwifi 0000:03:00.0: Current SW read_ptr 161 write_ptr 201
iwl data: 00000000: 00 00 00 00 00 00 00 00 fe ff 01 00 00 00 00 00
[snip]
iwlwifi 0000:03:00.0: FH TRBs(0) = 0x00000000
[snip]
iwlwifi 0000:03:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [9,9]
[snip]

Instead of waiting for these packets, simply drop them. This
significantly improves the responsiveness of the network.
Note that all the queues are flushed, but the VO one. This
is not typically used by the applications and it likely
contains management frames that are useful for connection
or roaming.

This bug is tracked here:
https://bugzilla.kernel.org/show_bug.cgi?id=56581

But it is duplicated in distributions' trackers.
A simple search in Ubuntu's database led to these bugs:

https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1270808
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1305406
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1356236
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1360597
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1361809

Depends-on: 77be2c54c5bd ("mac80211: add vif to flush call")
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: configure the LTR

2014-11-14T18:10:37+00:00

commit 9180ac50716a097a407c6d7e7e4589754a922260 upstream.

The LTR is the handshake between the device and the root
complex about the latency allowed when the bus exits power
save. This configuration was missing and this led to high
latency in the link power up. The end user could experience
high latency in the network because of this.

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

iwlwifi: mvm: BT Coex - update the MPLUT Boost register value

2014-11-14T18:10:37+00:00

commit d14b28fd2c61af0bf310230472e342864d799c98 upstream.

Fixes: 2adc8949efab ("iwlwifi: mvm: BT Coex - fix boost register / LUT values")
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

wireless: rt2x00: add new rt2800usb device

2014-11-14T18:10:33+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: Greg Kroah-Hartman

rt2x00: support Ralink 5362.

2014-11-14T18:10:33+00:00

commit ac0372abf8524a7572a9cdaac6495eb2eba20457 upstream.

Signed-off-by: Canek Peláez Valdés 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

fix misuses of f_count() in ppp and netlink

2014-11-14T18:10:24+00:00

commit 24dff96a37a2ca319e75a74d3929b2de22447ca6 upstream.

we used to check for "nobody else could start doing anything with
that opened file" by checking that refcount was 2 or less - one
for descriptor table and one we'd acquired in fget() on the way to
wherever we are.  That was race-prone (somebody else might have
had a reference to descriptor table and do fget() just as we'd
been checking) and it had become flat-out incorrect back when
we switched to fget_light() on those codepaths - unlike fget(),
it doesn't grab an extra reference unless the descriptor table
is shared.  The same change allowed a race-free check, though -
we are safe exactly when refcount is less than 2.

It was a long time ago; pre-2.6.12 for ioctl() (the codepath leading
to ppp one) and 2.6.17 for sendmsg() (netlink one).  OTOH,
netlink hadn't grown that check until 3.9 and ppp used to live
in drivers/net, not drivers/net/ppp until 3.1.  The bug existed
well before that, though, and the same fix used to apply in old
location of file.

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

stmmac: pci: set default of the filter bins

2014-11-14T18:10:21+00:00

[ Upstream commit 1e19e084eae727654052339757ab7f1eaff58bad ]

The commit 3b57de958e2a brought the support for a different amount of the
filter bins, but didn't update the PCI driver accordingly. This patch appends
the default values when the device is enumerated via PCI bus.

Fixes: 3b57de958e2a (net: stmmac: Support devicetree configs for mcast and ucast filter entries)
Signed-off-by: Andy Shevchenko 
Cc: stable@vger.kernel.org
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

drivers/net: macvtap and tun depend on INET

2014-11-14T18:10:21+00:00

[ Upstream commit de11b0e8c569b96c2cf6a811e3805b7aeef498a3 ]

These drivers now call ipv6_proxy_select_ident(), which is defined
only if CONFIG_INET is enabled.  However, they have really depended
on CONFIG_INET for as long as they have allowed sending GSO packets
from userland.

Reported-by: kbuild test robot 
Signed-off-by: Ben Hutchings 
Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
Fixes: b9fb9ee07e67 ("macvtap: add GSO/csum offload support")
Fixes: 5188cd44c55d ("drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets")
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets

2014-11-14T18:10:21+00:00

[ Upstream commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7 ]

UFO is now disabled on all drivers that work with virtio net headers,
but userland may try to send UFO/IPv6 packets anyway.  Instead of
sending with ID=0, we should select identifiers on their behalf (as we
used to).

Signed-off-by: Ben Hutchings 
Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman