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

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

skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard

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

[ Upstream commit a2af139ff1cd85df586690ff626619ab1ee88b0a ]

Marvell 88E8001 on an ASUS P5NSLI motherboard is unable to send/receive
packets on a system with >4gb ram unless a 32bit DMA mask is used.

This issue has been around for years and a fix was sent 3.5 years ago, but
there was some debate as to whether it should instead be fixed as a PCI quirk.
http://www.spinics.net/lists/netdev/msg88670.html

However, 18 months later a similar workaround was introduced for another
chipset exhibiting the same problem.
http://www.spinics.net/lists/netdev/msg142287.html

Signed-off-by: Graham Gower 
Signed-off-by: Jan Ceuleers 
Acked-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

e1000: fix vlan processing regression

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

commit 52f5509fe8ccb607ff9b84ad618f244262336475 upstream.

This patch fixes a regression introduced by commit "e1000: do vlan
cleanup (799d531)".

Apparently some e1000 chips (not mine) are sensitive about the order of
setting vlan filter and vlan stripping/inserting functionality. So this
patch changes the order so it's the same as before vlan cleanup.

Reported-by: Ben Greear 
Signed-off-by: Jiri Pirko 
Tested-by: Ben Greear 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
[Jonathan Nieder: It doesn't apply cleanly to kernels before
v3.3-rc1~182^2~581 (net: introduce and use netdev_features_t for
device features sets) but a backport is straightforward.]
Signed-off-by: Jonathan Nieder 
Tested-by: Andrey Jr. Melnikov 
Signed-off-by: Ben Hutchings

e1000: fix lockdep splat in shutdown handler

2012-10-17T02:50:10+00:00

commit 3a3847e007aae732d64d8fd1374126393e9879a3 upstream.

As reported by Steven Rostedt, e1000 has a lockdep splat added
during the recent merge window.  The issue is that
cancel_delayed_work is called while holding our private mutex.

There is no reason that I can see to hold the mutex during pci
shutdown, it was more just paranoia that I put the mutex_lock
around the call to e1000_down.

In a quick survey lots of drivers handle locking differently when
being called by the pci layer.  The assumption here is that we
don't need the mutexes' protection in this function because
the driver could not be unloaded while in the shutdown handler
which is only called at reboot or poweroff.

Reported-by: Steven Rostedt 
Signed-off-by: Jesse Brandeburg 
Tested-by: Steven Rostedt 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

r8169: 8168c and later require bit 0x20 to be set in Config2 for PME signaling.

2012-10-17T02:50:01+00:00

commit d387b427c973974dd619a33549c070ac5d0e089f upstream.

The new 84xx stopped flying below the radars.

Signed-off-by: Francois Romieu 
Cc: Hayes Wang 
Signed-off-by: Ben Hutchings