linux/drivers/net/ethernet, branch v3.4.93

ixgbe: fix registration order of driver and DCA nofitication

2014-06-07T23:02:14Z

commit f01fc1a82c2ee68726b400fadb156bd623b5f2f1 upstream. ixgbe_notify_dca cannot be called before driver registration because it expects driver's klist_devices to be allocated and initialized. While on it make sure debugfs files are removed when registration fails. Signed-off-by: Jakub Kicinski Tested-by: Phil Schmitt Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller [bwh: Backported to 3.2: no debugfs support] Signed-off-by: Ben Hutchings Cc: Qiang Huang Signed-off-by: Greg Kroah-Hartman

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

2014-06-07T23:02:07Z

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 Cc: Qiang Huang Signed-off-by: Greg Kroah-Hartman

tg3: update rx_jumbo_pending ring param only when jumbo frames are enabled

2014-06-07T23:01:59Z

The patch fixes a problem with dropped jumbo frames after usage of 'ethtool -G ... rx'. Scenario: 1. ip link set eth0 up 2. ethtool -G eth0 rx N # <- This zeroes rx-jumbo 3. ip link set mtu 9000 dev eth0 The ethtool command set rx_jumbo_pending to zero so any received jumbo packets are dropped and you need to use 'ethtool -G eth0 rx-jumbo N' to workaround the issue. The patch changes the logic so rx_jumbo_pending value is changed only if jumbo frames are enabled (MTU > 1500). Signed-off-by: Ivan Vecera Acked-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

list: introduce list_next_entry() and list_prev_entry()

2014-06-07T23:01:58Z

[ Upstream commit 008208c6b26f21c2648c250a09c55e737c02c5f8 ] Add two trivial helpers list_next_entry() and list_prev_entry(), they can have a lot of users including list.h itself. In fact the 1st one is already defined in events/core.c and bnx2x_sp.c, so the patch simply moves the definition to list.h. Signed-off-by: Oleg Nesterov Cc: Eilon Greenstein Cc: Greg Kroah-Hartman Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

tg3: Add read dma workaround for 5720

2014-04-14T13:44:32Z

commit 9bc297ea0622bb2a6b3abfa2fa84f0a3b86ef8c8 upstream. Commit 091f0ea30074bc43f9250961b3247af713024bc6 "tg3: Add New 5719 Read DMA workaround" added a workaround for TX DMA stall on the 5719. This workaround needs to be applied to the 5720 as well. Reported-by: Roland Dreier Tested-by: Roland Dreier Signed-off-by: Nithin Nayak Sujir Signed-off-by: Michael Chan Signed-off-by: David S. Miller [bwh: Backported to 3.2: use GET_ASIC_REV() instead of tg3_asic_rev()] Signed-off-by: Ben Hutchings [hq: Backproted to 3.4: Adjust context] Signed-off-by: Qiang Huang Signed-off-by: Greg Kroah-Hartman

tg3: Skip powering down function 0 on certain serdes devices

2014-04-14T13:44:32Z

commit 44f3b503c16425c8e9db4bbaa2fc9cd0c9d0ba91 upstream. On the 5718, 5719 and 5720 serdes devices, powering down function 0 results in all the other ports being powered down. Add code to skip function 0 power down. v2: - Modify tg3_phy_power_bug() function to use a switch instead of a complicated if statement. Suggested by Joe Perches. Signed-off-by: Michael Chan Signed-off-by: Nithin Nayak Sujir Signed-off-by: David S. Miller [bwh: Backported to 3.2: s/tg3_asic_rev\(tp\)/GET_ASIC_REV(tp->pci_chip_rev_id)/] Signed-off-by: Ben Hutchings [hq: Backported to 3.4: Adjust context] Signed-off-by: Qiang Huang Signed-off-by: Greg Kroah-Hartman

tg3: Wait for boot code to finish after power on

2014-04-14T13:44:32Z

commit df465abfe06f7dc4f33f4a96d17f096e9e8ac917 upstream. Some systems that don't need wake-on-lan may choose to power down the chip on system standby. Upon resume, the power on causes the boot code to startup and initialize the hardware. On one new platform, this is causing the device to go into a bad state due to a race between the driver and boot code, once every several hundred resumes. The same race exists on open since we come up from a power on. This patch adds a wait for boot code signature at the beginning of tg3_init_hw() which is common to both cases. If there has not been a power-off or the boot code has already completed, the signature will be present and poll_fw() returns immediately. Also return immediately if the device does not have firmware. Signed-off-by: Nithin Nayak Sujir Signed-off-by: Michael Chan Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Cc: Qiang Huang Signed-off-by: Greg Kroah-Hartman

tg3: Add New 5719 Read DMA workaround

2014-04-14T13:44:32Z

commit 091f0ea30074bc43f9250961b3247af713024bc6 upstream. After Power-on-reset, the 5719's TX DMA length registers may contain uninitialized values and cause TX DMA to stall. Check for invalid values and set a register bit to flush the TX channels. The bit needs to be turned off after the DMA channels have been flushed. Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings Cc: Qiang Huang Signed-off-by: Greg Kroah-Hartman

tg3: Don't check undefined error bits in RXBD

2014-03-24T04:37:04Z

[ Upstream commit d7b95315cc7f441418845a165ee56df723941487 ] Redefine the RXD_ERR_MASK to include only relevant error bits. This fixes a customer reported issue of randomly dropping packets on the 5719. Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

tg3: Fix deadlock in tg3_change_mtu()

2014-03-11T23:09:58Z

[ Upstream commit c6993dfd7db9b0c6b7ca7503a56fda9236a4710f ] Quoting David Vrabel - "5780 cards cannot have jumbo frames and TSO enabled together. When jumbo frames are enabled by setting the MTU, the TSO feature must be cleared. This is done indirectly by calling netdev_update_features() which will call tg3_fix_features() to actually clear the flags. netdev_update_features() will also trigger a new netlink message for the feature change event which will result in a call to tg3_get_stats64() which deadlocks on the tg3 lock." tg3_set_mtu() does not need to be under the tg3 lock since converting the flags to use set_bit(). Move it out to after tg3_netif_stop(). Reported-by: David Vrabel Tested-by: David Vrabel Signed-off-by: Michael Chan Signed-off-by: Nithin Nayak Sujir Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman