linux-stable.git/drivers/net, 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

ixgbe: add support for X540-AT1

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

commit df376f0de167754da9b3ece4afdb5bb8bf3fbf3e upstream.

This patch adds device support for Ethernet Controller X540-AT1.

Signed-off-by: Josh Hay 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

ixgbe: add support for new 82599 device id

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

commit 9e791e4a04c08868f02cd579a428a7268492e1b4 upstream.

Support for new 82599 based quad port adapter.

Signed-off-by: Emil Tantilov 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Ben Hutchings

sky2: Fix for interrupt handler

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

commit d663d181b9e92d80c2455e460e932d34e7a2a7ae upstream.

Re-enable interrupts if it is not our interrupt

Signed-off-by: Mirko Lindner 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

r8169: use unlimited DMA burst for TX

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

commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd upstream.

The r8169 driver currently limits the DMA burst for TX to 1024 bytes. I have
a box where this prevents the interface from using the gigabit line to its full
potential. This patch solves the problem by setting TX_DMA_BURST to unlimited.

The box has an ASRock B75M motherboard with on-board RTL8168evl/8111evl
(XID 0c900880). TSO is enabled.

I used netperf (TCP_STREAM test) to measure the dependency of TX throughput
on MTU. I did it for three different values of TX_DMA_BURST ('5'=512, '6'=1024,
'7'=unlimited). This chart shows the results:
http://michich.fedorapeople.org/r8169/r8169-effects-of-TX_DMA_BURST.png

Interesting points:
 - With the current DMA burst limit (1024):
   - at the default MTU=1500 I get only 842 Mbit/s.
   - when going from small MTU, the performance rises monotonically with
     increasing MTU only up to a peak at MTU=1076 (908 MBit/s). Then there's
     a sudden drop to 762 MBit/s from which the throughput rises monotonically
     again with further MTU increases.
 - With a smaller DMA burst limit (512):
   - there's a similar peak at MTU=1076 and another one at MTU=564.
 - With unlimited DMA burst:
   - at the default MTU=1500 I get nice 940 Mbit/s.
   - the throughput rises monotonically with increasing MTU with no strange
     peaks.

Notice that the peaks occur at MTU sizes that are multiples of the DMA burst
limit plus 52. Why 52? Because:
  20 (IP header) + 20 (TCP header) + 12 (TCP options) = 52

The Realtek-provided r8168 driver (v8.032.00) uses unlimited TX DMA burst too,
except for CFG_METHOD_1 where the TX DMA burst is set to 512 bytes.
CFG_METHOD_1 appears to be the oldest MAC version of "RTL8168B/8111B",
i.e. RTL_GIGA_MAC_VER_11 in r8169. Not sure if this MAC version really needs
the smaller burst limit, or if any other versions have similar requirements.

Signed-off-by: Michal Schmidt 
Acked-by: Francois Romieu 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

r8169: Fix WoL on RTL8168d/8111d.

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

commit b00e69dee4ccbb3a19989e3d4f1385bc2e3406cd upstream.

This regression was spotted between Debian squeeze and Debian wheezy
kernels (respectively based on 2.6.32 and 3.2). More info about
Wake-on-LAN issues with Realtek's 816x chipsets can be found in the
following thread: http://marc.info/?t=132079219400004

Probable regression from d4ed95d796e5126bba51466dc07e287cebc8bd19;
more chipsets are likely affected.

Tested on top of a 3.2.23 kernel.

Reported-by: Florent Fourcot 
Tested-by: Florent Fourcot 
Hinted-by: Francois Romieu 
Signed-off-by: Cyril Brulebois 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

r8169: allow multicast packets on sub-8168f chipset.

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

commit 0481776b7a70f09acf7d9d97c288c3a8403fbfe4 upstream.

RTL_GIGA_MAC_VER_35 includes no multicast hardware filter.

Signed-off-by: Nathan Walp 
Suggested-by: Hayes Wang 
Acked-by: Francois Romieu 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings