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

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

e1000e: DoS while TSO enabled caused by link partner with small MSS

2012-09-19T14:04:37+00:00

commit d821a4c4d11ad160925dab2bb009b8444beff484 upstream.

With a low enough MSS on the link partner and TSO enabled locally, the
networking stack can periodically send a very large (e.g.  64KB) TCP
message for which the driver will attempt to use more Tx descriptors than
are available by default in the Tx ring.  This is due to a workaround in
the code that imposes a limit of only 4 MSS-sized segments per descriptor
which appears to be a carry-over from the older e1000 driver and may be
applicable only to some older PCI or PCIx parts which are not supported in
e1000e.  When the driver gets a message that is too large to fit across the
configured number of Tx descriptors, it stops the upper stack from queueing
any more and gets stuck in this state.  After a timeout, the upper stack
assumes the adapter is hung and calls the driver to reset it.

Remove the unnecessary limitation of using up to only 4 MSS-sized segments
per Tx descriptor, and put in a hard failure test to catch when attempting
to check for message sizes larger than would fit in the whole Tx ring.
Refactor the remaining logic that limits the size of data per Tx descriptor
from a seemingly arbitrary 8KB to a limit based on the dynamic size of the
Tx packet buffer as described in the hardware specification.

Also, fix the logic in the check for space in the Tx ring for the next
largest possible packet after the current one has been successfully queued
for transmit, and use the appropriate defines for default ring sizes in
e1000_probe instead of magic values.

This issue goes back to the introduction of e1000e in 2.6.24 when it was
split off from e1000.

Reported-by: Ben Hutchings 
Signed-off-by: Bruce Allan 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2:
 - Adjust context
 - Adjust for use of net_device vs e1000_ring parameter]
Signed-off-by: Ben Hutchings

e1000e: NIC goes up and immediately goes down

2012-08-19T17:15:32+00:00

commit b7ec70be01a87f2c85df3ae11046e74f9b67e323 upstream.

Found that commit d478eb44 was a bad commit.
If the link partner is transmitting codeword (even if NULL codeword),
then the RXCW.C bit will be set so check for RXCW.CW is unnecessary.
Ref: RH BZ 840642

Reported-by: Fabio Futigami 
Signed-off-by: Tushar Dave 
CC: Marcelo Ricardo Leitner 
Tested-by: Aaron Brown 
Signed-off-by: Peter P Waskiewicz Jr 
Signed-off-by: Ben Hutchings

e1000: add dropped DMA receive enable back in for WoL

2012-08-19T17:15:26+00:00

commit b868179c47e9e8eadcd04c1f3105998e528988a3 upstream.

Commit d5bc77a223b0e9b9dfb002048d2b34a79e7d0b48 broke Wake-on-LAN by
inadvertently dropping the enabling of DMA receives.

Restore the enabling of DMA receives for WoL.

This is applicable to 3.1+ stable trees.

Reported-by: Tobias Klausmann 
Signed-off-by: Dean Nelson 
Tested-by: Tobias Klausmann 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Ben Hutchings

e1000e: Correct link check logic for 82571 serdes

2012-07-25T03:11:23+00:00

commit d0efa8f23a644f7cb7d1f8e78dd9a223efa412a3 upstream.

SYNCH bit and IV bit of RXCW register are sticky. Before examining these bits,
RXCW should be read twice to filter out one-time false events and have correct
values for these bits. Incorrect values of these bits in link check logic can
cause weird link stability issues if auto-negotiation fails.

Reported-by: Dean Nelson 
Signed-off-by: Tushar Dave 
Reviewed-by: Bruce Allan 
Tested-by: Jeff Pieper 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Ben Hutchings

e1000e: Remove special case for 82573/82574 ASPM L1 disablement

2012-07-04T04:44:12+00:00

commit 59aed95263bdd0e2b48eb9be5a94346d2d4abf90 upstream.

For the 82573, ASPM L1 gets disabled wholesale so this special-case code
is not required. For the 82574 the previous patch does the same as for
the 82573, disabling L1 on the adapter. Thus, this code is no longer
required and can be removed.

Signed-off-by: Chris Boot 
Tested-by: Jeff Pieper 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Ben Hutchings

e1000e: Disable ASPM L1 on 82574

2012-07-04T04:44:12+00:00

commit id d4a4206ebbaf48b55803a7eb34e330530d83a889

ASPM on the 82574 causes trouble. Currently the driver disables L0s for
this NIC but only disables L1 if the MTU is >1500. This patch simply
causes L1 to be disabled regardless of the MTU setting.

Signed-off-by: Chris Boot 
Cc: "Wyborny, Carolyn" 
Cc: Nix 
Link: https://lkml.org/lkml/2012/3/19/362
Tested-by: Jeff Pieper 
[Jeff Kirsher: Backport to 3.2-3.4 kernels]
Signed-off-by: Jeff Kirsher 
Signed-off-by: Ben Hutchings