[net-next 00/27][pull-request] Intel Wired LAN Driver Updates

[net-next 00/27][pull-request] Intel Wired LAN Driver Updates

[Jeff Kirsher]

Here are a batch of fixes and cleanups intended for 2.6.38.
The following changes since commit:

commit defb3519a64141608725e2dac5a5aa9a3c644bae
Author: David S. Miller <davem@davemloft.net>
Date:   Wed Dec 8 21:16:57 2010 -0800
  net: Abstract away all dst_entry metrics accesses

are available in the git repository at:

  master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6.git master

Bruce Allan (11):
  e1000e: 82571-based mezzanine card can fail ethtool link test
  e1000e: 82574/82583 performance improvement
  e1000e: 82577/8 must acquire h/w semaphore before workaround
  e1000e: 82571 Serdes can fail to get link
  e1000e: 82577/8/9 mis-configured OEM bits during S0->Sx
  e1000e: 82579 PHY incorrectly identified during init
  e1000e: support new PBA format from EEPROM
  e1000e: prevent null ptr dereference in e1000_tx_queue()
  e1000e: minor error message corrections
  e1000e: static analysis tools complain of a possible null ptr p
    dereference
  e1000e: increment the driver version

Carolyn Wyborny (1):
  igb: Add new function to read part number from EEPROM in string
    format

Dean Nelson (1):
  e1000: fix return value not set on error

Don Skidmore (3):
  ixgbe: fix X540 phy id to correct value
  ixgbe: fix X540 to use it's own info struct
  ixgbe: cleanup string function calls to use bound checking versions.

Emil Tantilov (2):
  ixgb: Don't check for vlan group on transmit
  ixgbe: fix ntuple support

Holger Eitzenberger (1):
  e1000e: fix double initialization in blink path

Jeff Kirsher (8):
  Documentation/networking/e1000.txt: Update documentation
  Documentation/networking/e1000e.txt: Update documentation
  Documentation/networking/igb.txt: update documentation
  Documentation/networking/igbvf.txt: Update documentation
  Documentation/networking/ixgbe.txt: Update ixgbe documentation
  Documentation/networking/ixgbevf.txt: Update documentation
  MAINTAINERS: Update Intel Wired LAN info
  Intel Wired LAN drivers: Use static const

 Documentation/networking/e1000.txt   |   10 +-
 Documentation/networking/e1000e.txt  |   40 ++++---
 Documentation/networking/igb.txt     |   22 +++-
 Documentation/networking/igbvf.txt   |    4 +-
 Documentation/networking/ixgbe.txt   |  211 ++++++++++++++++++++++------------
 Documentation/networking/ixgbevf.txt |    4 -
 MAINTAINERS                          |    2 +
 drivers/net/e1000/e1000_hw.c         |   20 ++--
 drivers/net/e1000/e1000_main.c       |   10 +-
 drivers/net/e1000/e1000_param.c      |   13 +-
 drivers/net/e1000e/82571.c           |   46 ++++++--
 drivers/net/e1000e/defines.h         |    8 +-
 drivers/net/e1000e/e1000.h           |    4 +-
 drivers/net/e1000e/ethtool.c         |   14 ++-
 drivers/net/e1000e/ich8lan.c         |   18 ++-
 drivers/net/e1000e/lib.c             |  135 ++++++++++++++++++----
 drivers/net/e1000e/netdev.c          |   21 ++--
 drivers/net/e1000e/param.c           |    2 +-
 drivers/net/e1000e/phy.c             |   25 +++-
 drivers/net/igb/e1000_defines.h      |    7 +
 drivers/net/igb/e1000_nvm.c          |   93 ++++++++++++++-
 drivers/net/igb/e1000_nvm.h          |    2 +
 drivers/net/igb/e1000_phy.c          |   11 +-
 drivers/net/igb/igb_main.c           |   11 +-
 drivers/net/ixgb/ixgb_main.c         |   51 +++++----
 drivers/net/ixgb/ixgb_param.c        |   21 ++--
 drivers/net/ixgbe/ixgbe_ethtool.c    |   31 +++--
 drivers/net/ixgbe/ixgbe_main.c       |   32 +++---
 drivers/net/ixgbe/ixgbe_phy.c        |    2 +-
 drivers/net/ixgbe/ixgbe_type.h       |    2 +-
 drivers/net/ixgbe/ixgbe_x540.c       |    4 +-
 drivers/net/ixgbevf/ethtool.c        |   18 ++-
 32 files changed, 624 insertions(+), 270 deletions(-)

-- 
1.7.3.2

[net-next 00/27][pull-request] Intel Wired LAN Driver Updates

[Jeff Kirsher]

Here are a batch of fixes and cleanups intended for 2.6.38.

v2- updated igb.txt and e1000e (patch 27) based on feedback from
    Ben Hutchings and Joe Perches.

The following changes since commit:

commit a5d62a149bb8f5359aff7ed7dce339752fbabfd9
Author: David S. Miller <davem@davemloft.net>
Date:   Fri Dec 10 16:49:24 2010 -0800
  isdn: Fix printed out copy_from_user() return value after previous change

are available in the git repository at:

  master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6.git master


Bruce Allan (11):
  e1000e: 82571-based mezzanine card can fail ethtool link test
  e1000e: 82574/82583 performance improvement
  e1000e: 82577/8 must acquire h/w semaphore before workaround
  e1000e: 82571 Serdes can fail to get link
  e1000e: 82577/8/9 mis-configured OEM bits during S0->Sx
  e1000e: 82579 PHY incorrectly identified during init
  e1000e: support new PBA format from EEPROM
  e1000e: prevent null ptr dereference in e1000_tx_queue()
  e1000e: minor error message corrections
  e1000e: static analysis tools complain of a possible null ptr p
    dereference
  e1000e: increment the driver version

Carolyn Wyborny (1):
  igb: Add new function to read part number from EEPROM in string
    format

Dean Nelson (1):
  e1000: fix return value not set on error

Don Skidmore (3):
  ixgbe: fix X540 phy id to correct value
  ixgbe: fix X540 to use it's own info struct
  ixgbe: cleanup string function calls to use bound checking versions.

Emil Tantilov (2):
  ixgb: Don't check for vlan group on transmit
  ixgbe: fix ntuple support

Holger Eitzenberger (1):
  e1000e: fix double initialization in blink path

Jeff Kirsher (8):
  Documentation/networking/e1000.txt: Update documentation
  Documentation/networking/e1000e.txt: Update documentation
  Documentation/networking/igb.txt: update documentation
  Documentation/networking/igbvf.txt: Update documentation
  Documentation/networking/ixgbe.txt: Update ixgbe documentation
  Documentation/networking/ixgbevf.txt: Update documentation
  MAINTAINERS: Update Intel Wired LAN info
  Intel Wired LAN drivers: Use static const

 Documentation/networking/e1000.txt   |   10 +-
 Documentation/networking/e1000e.txt  |   40 ++++---
 Documentation/networking/igb.txt     |   31 +-----
 Documentation/networking/igbvf.txt   |    4 +-
 Documentation/networking/ixgbe.txt   |  211 ++++++++++++++++++++++------------
 Documentation/networking/ixgbevf.txt |    4 -
 MAINTAINERS                          |    2 +
 drivers/net/e1000/e1000_hw.c         |   20 ++--
 drivers/net/e1000/e1000_main.c       |   10 +-
 drivers/net/e1000/e1000_param.c      |   13 +-
 drivers/net/e1000e/82571.c           |   46 ++++++--
 drivers/net/e1000e/defines.h         |    8 +-
 drivers/net/e1000e/e1000.h           |    4 +-
 drivers/net/e1000e/ethtool.c         |   13 ++-
 drivers/net/e1000e/ich8lan.c         |   18 ++-
 drivers/net/e1000e/lib.c             |  135 ++++++++++++++++++----
 drivers/net/e1000e/netdev.c          |   21 ++--
 drivers/net/e1000e/param.c           |    2 +-
 drivers/net/e1000e/phy.c             |   25 +++-
 drivers/net/igb/e1000_defines.h      |    7 +
 drivers/net/igb/e1000_nvm.c          |   93 ++++++++++++++-
 drivers/net/igb/e1000_nvm.h          |    2 +
 drivers/net/igb/e1000_phy.c          |   11 +-
 drivers/net/igb/igb_main.c           |   11 +-
 drivers/net/ixgb/ixgb_main.c         |   51 +++++----
 drivers/net/ixgb/ixgb_param.c        |   21 ++--
 drivers/net/ixgbe/ixgbe_ethtool.c    |   31 +++--
 drivers/net/ixgbe/ixgbe_main.c       |   32 +++---
 drivers/net/ixgbe/ixgbe_phy.c        |    2 +-
 drivers/net/ixgbe/ixgbe_type.h       |    2 +-
 drivers/net/ixgbe/ixgbe_x540.c       |    4 +-
 drivers/net/ixgbevf/ethtool.c        |   18 ++-
 32 files changed, 608 insertions(+), 294 deletions(-)

-- 
1.7.3.2

[PATCH 01/27] Documentation/networking/e1000.txt: Update documentation

[Jeff Kirsher]

Update Intel Wired LAN e1000 documentation.

Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 Documentation/networking/e1000.txt |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt
index d9271e7..6cb13e9 100644
--- a/Documentation/networking/e1000.txt
+++ b/Documentation/networking/e1000.txt
@@ -79,7 +79,7 @@ InterruptThrottleRate
 ---------------------
 (not supported on Intel(R) 82542, 82543 or 82544-based adapters)
 Valid Range:   0,1,3,4,100-100000 (0=off, 1=dynamic, 3=dynamic conservative,
-                                   4=simplified balancing)
+                                 4=simplified balancing)
 Default Value: 3
 
 The driver can limit the amount of interrupts per second that the adapter
@@ -124,8 +124,8 @@ InterruptThrottleRate is set to mode 1. In this mode, which operates
 the same as mode 3, the InterruptThrottleRate will be increased stepwise to
 70000 for traffic in class "Lowest latency".
 
-In simplified mode the interrupt rate is based on the ratio of Tx and
-Rx traffic.  If the bytes per second rate is approximately equal, the
+In simplified mode the interrupt rate is based on the ratio of TX and
+RX traffic.  If the bytes per second rate is approximately equal, the
 interrupt rate will drop as low as 2000 interrupts per second.  If the
 traffic is mostly transmit or mostly receive, the interrupt rate could
 be as high as 8000.
@@ -245,7 +245,7 @@ NOTE:  Depending on the available system resources, the request for a
 TxDescriptorStep
 ----------------
 Valid Range:    1 (use every Tx Descriptor)
-		4 (use every 4th Tx Descriptor)
+                4 (use every 4th Tx Descriptor)
 
 Default Value:  1 (use every Tx Descriptor)
 
@@ -312,7 +312,7 @@ Valid Range:   0-xxxxxxx (0=off)
 Default Value: 256
 Usage: insmod e1000.ko copybreak=128
 
-Driver copies all packets below or equaling this size to a fresh Rx
+Driver copies all packets below or equaling this size to a fresh RX
 buffer before handing it up the stack.
 
 This parameter is different than other parameters, in that it is a
-- 
1.7.3.2

[PATCH 02/27] Documentation/networking/e1000e.txt: Update documentation

[Jeff Kirsher]

Update Intel Wired LAN e1000e documentation.

Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 Documentation/networking/e1000e.txt |   40 +++++++++++++++++++---------------
 1 files changed, 22 insertions(+), 18 deletions(-)

diff --git a/Documentation/networking/e1000e.txt b/Documentation/networking/e1000e.txt
index 6aa048b..81a66e6 100644
--- a/Documentation/networking/e1000e.txt
+++ b/Documentation/networking/e1000e.txt
@@ -1,5 +1,5 @@
 Linux* Driver for Intel(R) Network Connection
-===============================================================
+=============================================
 
 Intel Gigabit Linux driver.
 Copyright(c) 1999 - 2010 Intel Corporation.
@@ -61,6 +61,12 @@ per second, even if more packets have come in. This reduces interrupt
 load on the system and can lower CPU utilization under heavy load,
 but will increase latency as packets are not processed as quickly.
 
+The default behaviour of the driver previously assumed a static
+InterruptThrottleRate value of 8000, providing a good fallback value for
+all traffic types, but lacking in small packet performance and latency.
+The hardware can handle many more small packets per second however, and
+for this reason an adaptive interrupt moderation algorithm was implemented.
+
 The driver has two adaptive modes (setting 1 or 3) in which
 it dynamically adjusts the InterruptThrottleRate value based on the traffic
 that it receives. After determining the type of incoming traffic in the last
@@ -86,8 +92,8 @@ InterruptThrottleRate is set to mode 1. In this mode, which operates
 the same as mode 3, the InterruptThrottleRate will be increased stepwise to
 70000 for traffic in class "Lowest latency".
 
-In simplified mode the interrupt rate is based on the ratio of Tx and
-Rx traffic.  If the bytes per second rate is approximately equal the
+In simplified mode the interrupt rate is based on the ratio of TX and
+RX traffic.  If the bytes per second rate is approximately equal, the
 interrupt rate will drop as low as 2000 interrupts per second.  If the
 traffic is mostly transmit or mostly receive, the interrupt rate could
 be as high as 8000.
@@ -177,7 +183,7 @@ Copybreak
 Valid Range:   0-xxxxxxx (0=off)
 Default Value: 256
 
-Driver copies all packets below or equaling this size to a fresh Rx
+Driver copies all packets below or equaling this size to a fresh RX
 buffer before handing it up the stack.
 
 This parameter is different than other parameters, in that it is a
@@ -223,17 +229,17 @@ loading or enabling the driver, try disabling this feature.
 
 WriteProtectNVM
 ---------------
-Valid Range: 0-1
-Default Value: 1 (enabled)
-
-Set the hardware to ignore all write/erase cycles to the GbE region in the
-ICHx NVM (non-volatile memory).  This feature can be disabled by the
-WriteProtectNVM module parameter (enabled by default) only after a hardware
-reset, but the machine must be power cycled before trying to enable writes.
-
-Note: the kernel boot option iomem=relaxed may need to be set if the kernel
-config option CONFIG_STRICT_DEVMEM=y, if the root user wants to write the
-NVM from user space via ethtool.
+Valid Range: 0,1
+Default Value: 1
+
+If set to 1, configure the hardware to ignore all write/erase cycles to the
+GbE region in the ICHx NVM (in order to prevent accidental corruption of the
+NVM). This feature can be disabled by setting the parameter to 0 during initial
+driver load.
+NOTE: The machine must be power cycled (full off/on) when enabling NVM writes
+via setting the parameter to zero. Once the NVM has been locked (via the
+parameter at 1 when the driver loads) it cannot be unlocked except via power
+cycle.
 
 Additional Configurations
 =========================
@@ -259,7 +265,6 @@ Additional Configurations
   - Some adapters limit Jumbo Frames sized packets to a maximum of
     4096 bytes and some adapters do not support Jumbo Frames.
 
-
   Ethtool
   -------
   The driver utilizes the ethtool interface for driver configuration and
@@ -283,8 +288,7 @@ Additional Configurations
   loaded when shutting down or rebooting the system.
 
   In most cases Wake On LAN is only supported on port A for multiple port
-  adapters. To verify if a port supports Wake on LAN run ethtool eth<X>.
-
+  adapters. To verify if a port supports Wake on Lan run Ethtool eth<X>.
 
 Support
 =======
-- 
1.7.3.2

[PATCH 03/27] Documentation/networking/igb.txt: update documentation

[Jeff Kirsher]

Update Intel Wired LAN igb documentation.

v2- Updated the ethtool support link, removed the LRO section and
    anti-spoofing sections.

Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 Documentation/networking/igb.txt |   31 ++++---------------------------
 1 files changed, 4 insertions(+), 27 deletions(-)

diff --git a/Documentation/networking/igb.txt b/Documentation/networking/igb.txt
index ab2d718..4a5e29c 100644
--- a/Documentation/networking/igb.txt
+++ b/Documentation/networking/igb.txt
@@ -36,6 +36,7 @@ Default Value: 0
 This parameter adds support for SR-IOV.  It causes the driver to spawn up to
 max_vfs worth of virtual function.
 
+
 Additional Configurations
 =========================
 
@@ -60,9 +61,10 @@ Additional Configurations
   Ethtool
   -------
   The driver utilizes the ethtool interface for driver configuration and
-  diagnostics, as well as displaying statistical information.
+  diagnostics, as well as displaying statistical information. The latest
+  version of Ethtool can be found at:
 
-  http://sourceforge.net/projects/gkernel.
+  http://ftp.kernel.org/pub/software/network/ethtool/
 
   Enabling Wake on LAN* (WoL)
   ---------------------------
@@ -91,31 +93,6 @@ Additional Configurations
   REQUIREMENTS: MSI-X support is required for Multiqueue. If MSI-X is not
   found, the system will fallback to MSI or to Legacy interrupts.
 
-  LRO
-  ---
-  Large Receive Offload (LRO) is a technique for increasing inbound throughput
-  of high-bandwidth network connections by reducing CPU overhead. It works by
-  aggregating multiple incoming packets from a single stream into a larger
-  buffer before they are passed higher up the networking stack, thus reducing
-  the number of packets that have to be processed. LRO combines multiple
-  Ethernet frames into a single receive in the stack, thereby potentially
-  decreasing CPU utilization for receives.
-
-  NOTE: You need to have inet_lro enabled via either the CONFIG_INET_LRO or
-  CONFIG_INET_LRO_MODULE kernel config option. Additionally, if
-  CONFIG_INET_LRO_MODULE is used, the inet_lro module needs to be loaded
-  before the igb driver.
-
-  You can verify that the driver is using LRO by looking at these counters in
-  Ethtool:
-
-  lro_aggregated - count of total packets that were combined
-  lro_flushed - counts the number of packets flushed out of LRO
-  lro_no_desc - counts the number of times an LRO descriptor was not available
-  for the LRO packet
-
-  NOTE: IPv6 and UDP are not supported by LRO.
-
 Support
 =======
 
-- 
1.7.3.2

[PATCH 04/27] Documentation/networking/igbvf.txt: Update documentation

[Jeff Kirsher]

Update Intel Wired LAN igbvf documentation.

Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 Documentation/networking/igbvf.txt |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/Documentation/networking/igbvf.txt b/Documentation/networking/igbvf.txt
index 0560281..694817b 100644
--- a/Documentation/networking/igbvf.txt
+++ b/Documentation/networking/igbvf.txt
@@ -58,7 +58,9 @@ Additional Configurations
   Ethtool
   -------
   The driver utilizes the ethtool interface for driver configuration and
-  diagnostics, as well as displaying statistical information.
+  diagnostics, as well as displaying statistical information.  Ethtool
+  version 3.0 or later is required for this functionality, although we
+  strongly recommend downloading the latest version at:
 
   http://sourceforge.net/projects/gkernel.
 
-- 
1.7.3.2

[PATCH 05/27] Documentation/networking/ixgbe.txt: Update ixgbe documentation

[Jeff Kirsher]

Update Intel Wired LAN ixgbe documentation.

Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 Documentation/networking/ixgbe.txt |  211 +++++++++++++++++++++++-------------
 1 files changed, 136 insertions(+), 75 deletions(-)

diff --git a/Documentation/networking/ixgbe.txt b/Documentation/networking/ixgbe.txt
index eeb6868..9ade280 100644
--- a/Documentation/networking/ixgbe.txt
+++ b/Documentation/networking/ixgbe.txt
@@ -1,107 +1,126 @@
 Linux Base Driver for 10 Gigabit PCI Express Intel(R) Network Connection
 ========================================================================
 
-March 10, 2009
-
+Intel Gigabit Linux driver.
+Copyright(c) 1999 - 2010 Intel Corporation.
 
 Contents
 ========
 
-- In This Release
 - Identifying Your Adapter
-- Building and Installation
 - Additional Configurations
+- Performance Tuning
+- Known Issues
 - Support
 
+Identifying Your Adapter
+========================
 
+The driver in this release is compatible with 82598 and 82599-based Intel
+Network Connections.
 
-In This Release
-===============
+For more information on how to identify your adapter, go to the Adapter &
+Driver ID Guide at:
 
-This file describes the ixgbe Linux Base Driver for the 10 Gigabit PCI
-Express Intel(R) Network Connection.  This driver includes support for
-Itanium(R)2-based systems.
+    http://support.intel.com/support/network/sb/CS-012904.htm
 
-For questions related to hardware requirements, refer to the documentation
-supplied with your 10 Gigabit adapter.  All hardware requirements listed apply
-to use with Linux.
+SFP+ Devices with Pluggable Optics
+----------------------------------
 
-The following features are available in this kernel:
- - Native VLANs
- - Channel Bonding (teaming)
- - SNMP
- - Generic Receive Offload
- - Data Center Bridging
+82599-BASED ADAPTERS
 
-Channel Bonding documentation can be found in the Linux kernel source:
-/Documentation/networking/bonding.txt
+NOTES: If your 82599-based Intel(R) Network Adapter came with Intel optics, or
+is an Intel(R) Ethernet Server Adapter X520-2, then it only supports Intel
+optics and/or the direct attach cables listed below.
 
-Ethtool, lspci, and ifconfig can be used to display device and driver
-specific information.
+When 82599-based SFP+ devices are connected back to back, they should be set to
+the same Speed setting via Ethtool. Results may vary if you mix speed settings.
+82598-based adapters support all passive direct attach cables that comply
+with SFF-8431 v4.1 and SFF-8472 v10.4 specifications. Active direct attach
+cables are not supported.
 
+Supplier    Type                                             Part Numbers
 
-Identifying Your Adapter
-========================
+SR Modules
+Intel       DUAL RATE 1G/10G SFP+ SR (bailed)                FTLX8571D3BCV-IT
+Intel       DUAL RATE 1G/10G SFP+ SR (bailed)                AFBR-703SDDZ-IN1
+Intel       DUAL RATE 1G/10G SFP+ SR (bailed)                AFBR-703SDZ-IN2
+LR Modules
+Intel       DUAL RATE 1G/10G SFP+ LR (bailed)                FTLX1471D3BCV-IT
+Intel       DUAL RATE 1G/10G SFP+ LR (bailed)                AFCT-701SDDZ-IN1
+Intel       DUAL RATE 1G/10G SFP+ LR (bailed)                AFCT-701SDZ-IN2
 
-This driver supports devices based on the 82598 controller and the 82599
-controller.
+The following is a list of 3rd party SFP+ modules and direct attach cables that
+have received some testing. Not all modules are applicable to all devices.
 
-For specific information on identifying which adapter you have, please visit:
+Supplier   Type                                              Part Numbers
 
-    http://support.intel.com/support/network/sb/CS-008441.htm
+Finisar    SFP+ SR bailed, 10g single rate                   FTLX8571D3BCL
+Avago      SFP+ SR bailed, 10g single rate                   AFBR-700SDZ
+Finisar    SFP+ LR bailed, 10g single rate                   FTLX1471D3BCL
 
+Finisar    DUAL RATE 1G/10G SFP+ SR (No Bail)                FTLX8571D3QCV-IT
+Avago      DUAL RATE 1G/10G SFP+ SR (No Bail)                AFBR-703SDZ-IN1
+Finisar    DUAL RATE 1G/10G SFP+ LR (No Bail)                FTLX1471D3QCV-IT
+Avago      DUAL RATE 1G/10G SFP+ LR (No Bail)                AFCT-701SDZ-IN1
+Finistar   1000BASE-T SFP                                    FCLF8522P2BTL
+Avago      1000BASE-T SFP                                    ABCU-5710RZ
 
-Building and Installation
-=========================
+82599-based adapters support all passive and active limiting direct attach
+cables that comply with SFF-8431 v4.1 and SFF-8472 v10.4 specifications.
 
-select m for "Intel(R) 10GbE PCI Express adapters support" located at:
-      Location:
-        -> Device Drivers
-          -> Network device support (NETDEVICES [=y])
-            -> Ethernet (10000 Mbit) (NETDEV_10000 [=y])
+Laser turns off for SFP+ when ifconfig down
+-------------------------------------------
+"ifconfig down" turns off the laser for 82599-based SFP+ fiber adapters.
+"ifconfig up" turns on the later.
 
-1. make modules & make modules_install
 
-2. Load the module:
+82598-BASED ADAPTERS
 
-# modprobe ixgbe
+NOTES for 82598-Based Adapters:
+- Intel(R) Network Adapters that support removable optical modules only support
+  their original module type (i.e., the Intel(R) 10 Gigabit SR Dual Port
+  Express Module only supports SR optical modules). If you plug in a different
+  type of module, the driver will not load.
+- Hot Swapping/hot plugging optical modules is not supported.
+- Only single speed, 10 gigabit modules are supported.
+- LAN on Motherboard (LOMs) may support DA, SR, or LR modules. Other module
+  types are not supported. Please see your system documentation for details.
 
-   The insmod command can be used if the full
-   path to the driver module is specified.  For example:
+The following is a list of 3rd party SFP+ modules and direct attach cables that
+have received some testing. Not all modules are applicable to all devices.
 
-     insmod /lib/modules/<KERNEL VERSION>/kernel/drivers/net/ixgbe/ixgbe.ko
+Supplier   Type                                              Part Numbers
 
-   With 2.6 based kernels also make sure that older ixgbe drivers are
-   removed from the kernel, before loading the new module:
+Finisar    SFP+ SR bailed, 10g single rate                   FTLX8571D3BCL
+Avago      SFP+ SR bailed, 10g single rate                   AFBR-700SDZ
+Finisar    SFP+ LR bailed, 10g single rate                   FTLX1471D3BCL
 
-     rmmod ixgbe; modprobe ixgbe
+82598-based adapters support all passive direct attach cables that comply
+with SFF-8431 v4.1 and SFF-8472 v10.4 specifications. Active direct attach
+cables are not supported.
 
-3. Assign an IP address to the interface by entering the following, where
-   x is the interface number:
 
-     ifconfig ethx <IP_address>
+Flow Control
+------------
+Ethernet Flow Control (IEEE 802.3x) can be configured with ethtool to enable
+receiving and transmitting pause frames for ixgbe. When TX is enabled, PAUSE
+frames are generated when the receive packet buffer crosses a predefined
+threshold.  When rx is enabled, the transmit unit will halt for the time delay
+specified when a PAUSE frame is received.
 
-4. Verify that the interface works. Enter the following, where <IP_address>
-   is the IP address for another machine on the same subnet as the interface
-   that is being tested:
+Flow Control is enabled by default. If you want to disable a flow control
+capable link partner, use Ethtool:
 
-     ping  <IP_address>
+     ethtool -A eth? autoneg off RX off TX off
 
+NOTE: For 82598 backplane cards entering 1 gig mode, flow control default
+behavior is changed to off.  Flow control in 1 gig mode on these devices can
+lead to Tx hangs.
 
 Additional Configurations
 =========================
 
-  Viewing Link Messages
-  ---------------------
-  Link messages will not be displayed to the console if the distribution is
-  restricting system messages. In order to see network driver link messages on
-  your console, set dmesg to eight by entering the following:
-
-       dmesg -n 8
-
-  NOTE: This setting is not saved across reboots.
-
-
   Jumbo Frames
   ------------
   The driver supports Jumbo Frames for all adapters. Jumbo Frames support is
@@ -123,13 +142,8 @@ Additional Configurations
   other protocols besides TCP.  It's also safe to use with configurations that
   are problematic for LRO, namely bridging and iSCSI.
 
-  GRO is enabled by default in the driver.  Future versions of ethtool will
-  support disabling and re-enabling GRO on the fly.
-
-
   Data Center Bridging, aka DCB
   -----------------------------
-
   DCB is a configuration Quality of Service implementation in hardware.
   It uses the VLAN priority tag (802.1p) to filter traffic.  That means
   that there are 8 different priorities that traffic can be filtered into.
@@ -163,24 +177,71 @@ Additional Configurations
 
         http://e1000.sf.net
 
-
   Ethtool
   -------
   The driver utilizes the ethtool interface for driver configuration and
-  diagnostics, as well as displaying statistical information.  Ethtool
-  version 3.0 or later is required for this functionality.
+  diagnostics, as well as displaying statistical information. The latest
+  Ethtool version is required for this functionality.
 
   The latest release of ethtool can be found from
   http://sourceforge.net/projects/gkernel.
 
-
-  NAPI
+  FCoE
   ----
+  This release of the ixgbe driver contains new code to enable users to use
+  Fiber Channel over Ethernet (FCoE) and Data Center Bridging (DCB)
+  functionality that is supported by the 82598-based hardware.  This code has
+  no default effect on the regular driver operation, and configuring DCB and
+  FCoE is outside the scope of this driver README. Refer to
+  http://www.open-fcoe.org/ for FCoE project information and contact
+  e1000-eedc@lists.sourceforge.net for DCB information.
+
+  MAC and VLAN anti-spoofing feature
+  ----------------------------------
+  When a malicious driver attempts to send a spoofed packet, it is dropped by
+  the hardware and not transmitted.  An interrupt is sent to the PF driver
+  notifying it of the spoof attempt.
+
+  When a spoofed packet is detected the PF driver will send the following
+  message to the system log (displayed by  the "dmesg" command):
+
+  Spoof event(s) detected on VF (n)
+
+  Where n=the VF that attempted to do the spoofing.
+
+
+Performance Tuning
+==================
+
+An excellent article on performance tuning can be found at:
+
+http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf
+
+
+Known Issues
+============
+
+  Enabling SR-IOV in a 32-bit Microsoft* Windows* Server 2008 Guest OS using
+  Intel (R) 82576-based GbE or Intel (R) 82599-based 10GbE controller under KVM
+  -----------------------------------------------------------------------------
+  KVM Hypervisor/VMM supports direct assignment of a PCIe device to a VM.  This
+  includes traditional PCIe devices, as well as SR-IOV-capable devices using
+  Intel 82576-based and 82599-based controllers.
+
+  While direct assignment of a PCIe device or an SR-IOV Virtual Function (VF)
+  to a Linux-based VM running 2.6.32 or later kernel works fine, there is a
+  known issue with Microsoft Windows Server 2008 VM that results in a "yellow
+  bang" error. This problem is within the KVM VMM itself, not the Intel driver,
+  or the SR-IOV logic of the VMM, but rather that KVM emulates an older CPU
+  model for the guests, and this older CPU model does not support MSI-X
+  interrupts, which is a requirement for Intel SR-IOV.
 
-  NAPI (Rx polling mode) is supported in the ixgbe driver.  NAPI is enabled
-  by default in the driver.
+  If you wish to use the Intel 82576 or 82599-based controllers in SR-IOV mode
+  with KVM and a Microsoft Windows Server 2008 guest try the following
+  workaround. The workaround is to tell KVM to emulate a different model of CPU
+  when using qemu to create the KVM guest:
 
-  See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI.
+       "-cpu qemu64,model=13"
 
 
 Support
-- 
1.7.3.2

[PATCH 06/27] Documentation/networking/ixgbevf.txt: Update documentation

[Jeff Kirsher]

Update Intel Wired LAN ixgbevf documentation.

Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 Documentation/networking/ixgbevf.txt |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/Documentation/networking/ixgbevf.txt b/Documentation/networking/ixgbevf.txt
index 21dd5d1..5a91a41 100644
--- a/Documentation/networking/ixgbevf.txt
+++ b/Documentation/networking/ixgbevf.txt
@@ -35,10 +35,6 @@ Driver ID Guide at:
 Known Issues/Troubleshooting
 ============================
 
-  Unloading Physical Function (PF) Driver Causes System Reboots When VM is
-  Running and VF is Loaded on the VM
-  ------------------------------------------------------------------------
-  Do not unload the PF driver (ixgbe) while VFs are assigned to guests.
 
 Support
 =======
-- 
1.7.3.2

[PATCH 07/27] MAINTAINERS: Update Intel Wired LAN info

[Jeff Kirsher]

Update with Intel Wired Ethernet public git trees.

Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 MAINTAINERS |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9206cb4..4a77d0d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3115,6 +3115,8 @@ M:	Alex Duyck <alexander.h.duyck@intel.com>
 M:	John Ronciak <john.ronciak@intel.com>
 L:	e1000-devel@lists.sourceforge.net
 W:	http://e1000.sourceforge.net/
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-2.6.git
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next-2.6.git
 S:	Supported
 F:	Documentation/networking/e100.txt
 F:	Documentation/networking/e1000.txt
-- 
1.7.3.2

[PATCH 08/27] e1000: fix return value not set on error

[Jeff Kirsher]

From: Dean Nelson <dnelson@redhat.com>

Dean noticed that 'err' wasn't being set when the "goto err_dma"
statement is executed in the following hunk from the commit. It's value
will be zero as a result of a successful call to e1000_init_hw_struct().

This patch changes the error condition to be correctly propagated.

CC: stable@kernel.org
Signed-off-by:  Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/e1000/e1000_main.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 06c7d1c..491bf2a 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -971,11 +971,13 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
 		 */
 		dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
 		pci_using_dac = 1;
-	} else if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(32))) {
-		dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
 	} else {
-		pr_err("No usable DMA config, aborting\n");
-		goto err_dma;
+		err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+		if (err) {
+			pr_err("No usable DMA config, aborting\n");
+			goto err_dma;
+		}
+		dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
 	}
 
 	netdev->netdev_ops = &e1000_netdev_ops;
-- 
1.7.3.2

[PATCH 08/27] e1000: fix return value not set on error

[Jeff Kirsher]

From: Dean Nelson <dnelson@redhat.com>

Dean noticed that 'err' wasn't being set when the "goto err_dma"
statement is executed in the following hunk from the commit. It's value
will be zero as a result of a successful call to e1000_init_hw_struct().

This patch changes the error condition to be correctly propagated.

CC: stable@kernel.org
Signed-off-by:  Dean Nelson <dnelson@redhat.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/e1000/e1000_main.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 06c7d1c..491bf2a 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -971,11 +971,13 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
 		 */
 		dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
 		pci_using_dac = 1;
-	} else if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(32))) {
-		dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
 	} else {
-		pr_err("No usable DMA config, aborting\n");
-		goto err_dma;
+		err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+		if (err) {
+			pr_err("No usable DMA config, aborting\n");
+			goto err_dma;
+		}
+		dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
 	}
 
 	netdev->netdev_ops = &e1000_netdev_ops;
-- 
1.7.3.2

[PATCH 09/27] Intel Wired LAN drivers: Use static const

[Jeff Kirsher]

Based on work by Joe Perches <joe@perches.com>

Using static const to decrease data and overall object size.

CC: Joe Perches <joe@perches.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
---
 drivers/net/e1000/e1000_hw.c      |   20 ++++++++++----------
 drivers/net/e1000/e1000_param.c   |   13 +++++++------
 drivers/net/e1000e/phy.c          |   11 ++++++-----
 drivers/net/igb/e1000_phy.c       |   11 ++++++-----
 drivers/net/ixgb/ixgb_param.c     |   21 +++++++++++----------
 drivers/net/ixgbe/ixgbe_ethtool.c |   24 ++++++++++++++----------
 drivers/net/ixgbevf/ethtool.c     |   18 +++++++++++-------
 7 files changed, 65 insertions(+), 53 deletions(-)

diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
index c7e242b6..77d08e6 100644
--- a/drivers/net/e1000/e1000_hw.c
+++ b/drivers/net/e1000/e1000_hw.c
@@ -4892,11 +4892,11 @@ static s32 e1000_get_cable_length(struct e1000_hw *hw, u16 *min_length,
 	} else if (hw->phy_type == e1000_phy_igp) {	/* For IGP PHY */
 		u16 cur_agc_value;
 		u16 min_agc_value = IGP01E1000_AGC_LENGTH_TABLE_SIZE;
-		u16 agc_reg_array[IGP01E1000_PHY_CHANNEL_NUM] =
-		    { IGP01E1000_PHY_AGC_A,
-			IGP01E1000_PHY_AGC_B,
-			IGP01E1000_PHY_AGC_C,
-			IGP01E1000_PHY_AGC_D
+		static const u16 agc_reg_array[IGP01E1000_PHY_CHANNEL_NUM] = {
+		       IGP01E1000_PHY_AGC_A,
+		       IGP01E1000_PHY_AGC_B,
+		       IGP01E1000_PHY_AGC_C,
+		       IGP01E1000_PHY_AGC_D
 		};
 		/* Read the AGC registers for all channels */
 		for (i = 0; i < IGP01E1000_PHY_CHANNEL_NUM; i++) {
@@ -5071,11 +5071,11 @@ static s32 e1000_config_dsp_after_link_change(struct e1000_hw *hw, bool link_up)
 {
 	s32 ret_val;
 	u16 phy_data, phy_saved_data, speed, duplex, i;
-	u16 dsp_reg_array[IGP01E1000_PHY_CHANNEL_NUM] =
-	    { IGP01E1000_PHY_AGC_PARAM_A,
-		IGP01E1000_PHY_AGC_PARAM_B,
-		IGP01E1000_PHY_AGC_PARAM_C,
-		IGP01E1000_PHY_AGC_PARAM_D
+	static const u16 dsp_reg_array[IGP01E1000_PHY_CHANNEL_NUM] = {
+	       IGP01E1000_PHY_AGC_PARAM_A,
+	       IGP01E1000_PHY_AGC_PARAM_B,
+	       IGP01E1000_PHY_AGC_PARAM_C,
+	       IGP01E1000_PHY_AGC_PARAM_D
 	};
 	u16 min_length, max_length;
 
diff --git a/drivers/net/e1000/e1000_param.c b/drivers/net/e1000/e1000_param.c
index 10d8d98..1301eba 100644
--- a/drivers/net/e1000/e1000_param.c
+++ b/drivers/net/e1000/e1000_param.c
@@ -352,12 +352,13 @@ void __devinit e1000_check_options(struct e1000_adapter *adapter)
 	}
 	{ /* Flow Control */
 
-		struct e1000_opt_list fc_list[] =
-			{{ E1000_FC_NONE,    "Flow Control Disabled" },
-			 { E1000_FC_RX_PAUSE,"Flow Control Receive Only" },
-			 { E1000_FC_TX_PAUSE,"Flow Control Transmit Only" },
-			 { E1000_FC_FULL,    "Flow Control Enabled" },
-			 { E1000_FC_DEFAULT, "Flow Control Hardware Default" }};
+		static const struct e1000_opt_list fc_list[] = {
+		       { E1000_FC_NONE, "Flow Control Disabled" },
+		       { E1000_FC_RX_PAUSE, "Flow Control Receive Only" },
+		       { E1000_FC_TX_PAUSE, "Flow Control Transmit Only" },
+		       { E1000_FC_FULL, "Flow Control Enabled" },
+		       { E1000_FC_DEFAULT, "Flow Control Hardware Default" }
+		};
 
 		opt = (struct e1000_option) {
 			.type = list_option,
diff --git a/drivers/net/e1000e/phy.c b/drivers/net/e1000e/phy.c
index 3d3dc0c..6ad90cc 100644
--- a/drivers/net/e1000e/phy.c
+++ b/drivers/net/e1000e/phy.c
@@ -1840,11 +1840,12 @@ s32 e1000e_get_cable_length_igp_2(struct e1000_hw *hw)
 	u16 phy_data, i, agc_value = 0;
 	u16 cur_agc_index, max_agc_index = 0;
 	u16 min_agc_index = IGP02E1000_CABLE_LENGTH_TABLE_SIZE - 1;
-	u16 agc_reg_array[IGP02E1000_PHY_CHANNEL_NUM] =
-							 {IGP02E1000_PHY_AGC_A,
-							  IGP02E1000_PHY_AGC_B,
-							  IGP02E1000_PHY_AGC_C,
-							  IGP02E1000_PHY_AGC_D};
+	static const u16 agc_reg_array[IGP02E1000_PHY_CHANNEL_NUM] = {
+	       IGP02E1000_PHY_AGC_A,
+	       IGP02E1000_PHY_AGC_B,
+	       IGP02E1000_PHY_AGC_C,
+	       IGP02E1000_PHY_AGC_D
+	};
 
 	/* Read the AGC registers for all channels */
 	for (i = 0; i < IGP02E1000_PHY_CHANNEL_NUM; i++) {
diff --git a/drivers/net/igb/e1000_phy.c b/drivers/net/igb/e1000_phy.c
index ddd036a..6694bf3 100644
--- a/drivers/net/igb/e1000_phy.c
+++ b/drivers/net/igb/e1000_phy.c
@@ -1757,11 +1757,12 @@ s32 igb_get_cable_length_igp_2(struct e1000_hw *hw)
 	u16 phy_data, i, agc_value = 0;
 	u16 cur_agc_index, max_agc_index = 0;
 	u16 min_agc_index = IGP02E1000_CABLE_LENGTH_TABLE_SIZE - 1;
-	u16 agc_reg_array[IGP02E1000_PHY_CHANNEL_NUM] =
-							 {IGP02E1000_PHY_AGC_A,
-							  IGP02E1000_PHY_AGC_B,
-							  IGP02E1000_PHY_AGC_C,
-							  IGP02E1000_PHY_AGC_D};
+	static const u16 agc_reg_array[IGP02E1000_PHY_CHANNEL_NUM] = {
+	       IGP02E1000_PHY_AGC_A,
+	       IGP02E1000_PHY_AGC_B,
+	       IGP02E1000_PHY_AGC_C,
+	       IGP02E1000_PHY_AGC_D
+	};
 
 	/* Read the AGC registers for all channels */
 	for (i = 0; i < IGP02E1000_PHY_CHANNEL_NUM; i++) {
diff --git a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c
index 88a08f0..dd7fbeb 100644
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -191,9 +191,9 @@ struct ixgb_option {
 		} r;
 		struct {	/* list_option info */
 			int nr;
-			struct ixgb_opt_list {
+			const struct ixgb_opt_list {
 				int i;
-				char *str;
+				const char *str;
 			} *p;
 		} l;
 	} arg;
@@ -226,7 +226,7 @@ ixgb_validate_option(unsigned int *value, const struct ixgb_option *opt)
 		break;
 	case list_option: {
 		int i;
-		struct ixgb_opt_list *ent;
+		const struct ixgb_opt_list *ent;
 
 		for (i = 0; i < opt->arg.l.nr; i++) {
 			ent = &opt->arg.l.p[i];
@@ -322,14 +322,15 @@ ixgb_check_options(struct ixgb_adapter *adapter)
 	}
 	{ /* Flow Control */
 
-		struct ixgb_opt_list fc_list[] =
-			{{ ixgb_fc_none,	"Flow Control Disabled" },
-			 { ixgb_fc_rx_pause,"Flow Control Receive Only" },
-			 { ixgb_fc_tx_pause,"Flow Control Transmit Only" },
-			 { ixgb_fc_full,	"Flow Control Enabled" },
-			 { ixgb_fc_default, "Flow Control Hardware Default" }};
+		static const struct ixgb_opt_list fc_list[] = {
+		       { ixgb_fc_none, "Flow Control Disabled" },
+		       { ixgb_fc_rx_pause, "Flow Control Receive Only" },
+		       { ixgb_fc_tx_pause, "Flow Control Transmit Only" },
+		       { ixgb_fc_full, "Flow Control Enabled" },
+		       { ixgb_fc_default, "Flow Control Hardware Default" }
+		};
 
-		const struct ixgb_option opt = {
+		static const struct ixgb_option opt = {
 			.type = list_option,
 			.name = "Flow Control",
 			.err  = "reading default settings from EEPROM",
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index ef3f910..90a740d 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -1157,7 +1157,7 @@ struct ixgbe_reg_test {
 #define TABLE64_TEST_HI	6
 
 /* default 82599 register test */
-static struct ixgbe_reg_test reg_test_82599[] = {
+static const struct ixgbe_reg_test reg_test_82599[] = {
 	{ IXGBE_FCRTL_82599(0), 1, PATTERN_TEST, 0x8007FFF0, 0x8007FFF0 },
 	{ IXGBE_FCRTH_82599(0), 1, PATTERN_TEST, 0x8007FFF0, 0x8007FFF0 },
 	{ IXGBE_PFCTOP, 1, PATTERN_TEST, 0xFFFFFFFF, 0xFFFFFFFF },
@@ -1181,7 +1181,7 @@ static struct ixgbe_reg_test reg_test_82599[] = {
 };
 
 /* default 82598 register test */
-static struct ixgbe_reg_test reg_test_82598[] = {
+static const struct ixgbe_reg_test reg_test_82598[] = {
 	{ IXGBE_FCRTL(0), 1, PATTERN_TEST, 0x8007FFF0, 0x8007FFF0 },
 	{ IXGBE_FCRTH(0), 1, PATTERN_TEST, 0x8007FFF0, 0x8007FFF0 },
 	{ IXGBE_PFCTOP, 1, PATTERN_TEST, 0xFFFFFFFF, 0xFFFFFFFF },
@@ -1208,18 +1208,22 @@ static struct ixgbe_reg_test reg_test_82598[] = {
 	{ 0, 0, 0, 0 }
 };
 
+static const u32 register_test_patterns[] = {
+	0x5A5A5A5A, 0xA5A5A5A5, 0x00000000, 0xFFFFFFFF
+};
+
 #define REG_PATTERN_TEST(R, M, W)                                             \
 {                                                                             \
 	u32 pat, val, before;                                                 \
-	const u32 _test[] = {0x5A5A5A5A, 0xA5A5A5A5, 0x00000000, 0xFFFFFFFF}; \
-	for (pat = 0; pat < ARRAY_SIZE(_test); pat++) {                       \
+	for (pat = 0; pat < ARRAY_SIZE(register_test_patterns); pat++) {      \
 		before = readl(adapter->hw.hw_addr + R);                      \
-		writel((_test[pat] & W), (adapter->hw.hw_addr + R));          \
+		writel((register_test_patterns[pat] & W),                     \
+		       (adapter->hw.hw_addr + R));                            \
 		val = readl(adapter->hw.hw_addr + R);                         \
-		if (val != (_test[pat] & W & M)) {                            \
-			e_err(drv, "pattern test reg %04X failed: got "   \
-			      "0x%08X expected 0x%08X\n",		      \
-			      R, val, (_test[pat] & W & M));                \
+		if (val != (register_test_patterns[pat] & W & M)) {           \
+			e_err(drv, "pattern test reg %04X failed: got "       \
+			      "0x%08X expected 0x%08X\n",                     \
+			      R, val, (register_test_patterns[pat] & W & M)); \
 			*data = R;                                            \
 			writel(before, adapter->hw.hw_addr + R);              \
 			return 1;                                             \
@@ -1246,7 +1250,7 @@ static struct ixgbe_reg_test reg_test_82598[] = {
 
 static int ixgbe_reg_test(struct ixgbe_adapter *adapter, u64 *data)
 {
-	struct ixgbe_reg_test *test;
+	const struct ixgbe_reg_test *test;
 	u32 value, before, after;
 	u32 i, toggle;
 
diff --git a/drivers/net/ixgbevf/ethtool.c b/drivers/net/ixgbevf/ethtool.c
index 4cc817a..fa29b3c 100644
--- a/drivers/net/ixgbevf/ethtool.c
+++ b/drivers/net/ixgbevf/ethtool.c
@@ -544,7 +544,7 @@ struct ixgbevf_reg_test {
 #define TABLE64_TEST_HI	6
 
 /* default VF register test */
-static struct ixgbevf_reg_test reg_test_vf[] = {
+static const struct ixgbevf_reg_test reg_test_vf[] = {
 	{ IXGBE_VFRDBAL(0), 2, PATTERN_TEST, 0xFFFFFF80, 0xFFFFFF80 },
 	{ IXGBE_VFRDBAH(0), 2, PATTERN_TEST, 0xFFFFFFFF, 0xFFFFFFFF },
 	{ IXGBE_VFRDLEN(0), 2, PATTERN_TEST, 0x000FFF80, 0x000FFFFF },
@@ -557,19 +557,23 @@ static struct ixgbevf_reg_test reg_test_vf[] = {
 	{ 0, 0, 0, 0 }
 };
 
+static const u32 register_test_patterns[] = {
+	0x5A5A5A5A, 0xA5A5A5A5, 0x00000000, 0xFFFFFFFF
+};
+
 #define REG_PATTERN_TEST(R, M, W)                                             \
 {                                                                             \
 	u32 pat, val, before;                                                 \
-	const u32 _test[] = {0x5A5A5A5A, 0xA5A5A5A5, 0x00000000, 0xFFFFFFFF}; \
-	for (pat = 0; pat < ARRAY_SIZE(_test); pat++) {                       \
+	for (pat = 0; pat < ARRAY_SIZE(register_test_patterns); pat++) {      \
 		before = readl(adapter->hw.hw_addr + R);                      \
-		writel((_test[pat] & W), (adapter->hw.hw_addr + R));          \
+		writel((register_test_patterns[pat] & W),                     \
+		       (adapter->hw.hw_addr + R));                            \
 		val = readl(adapter->hw.hw_addr + R);                         \
-		if (val != (_test[pat] & W & M)) {                            \
+		if (val != (register_test_patterns[pat] & W & M)) {           \
 			hw_dbg(&adapter->hw,                                  \
 			"pattern test reg %04X failed: got "                  \
 			"0x%08X expected 0x%08X\n",                           \
-			R, val, (_test[pat] & W & M));                        \
+			R, val, (register_test_patterns[pat] & W & M));       \
 			*data = R;                                            \
 			writel(before, adapter->hw.hw_addr + R);              \
 			return 1;                                             \
@@ -596,7 +600,7 @@ static struct ixgbevf_reg_test reg_test_vf[] = {
 
 static int ixgbevf_reg_test(struct ixgbevf_adapter *adapter, u64 *data)
 {
-	struct ixgbevf_reg_test *test;
+	const struct ixgbevf_reg_test *test;
 	u32 i;
 
 	test = reg_test_vf;
-- 
1.7.3.2

[PATCH 10/27] ixgb: Don't check for vlan group on transmit

[Jeff Kirsher]

From: Emil Tantilov <emil.s.tantilov@intel.com>

Based on a patch from Jesse Gross.

Enable vlan tag insertion even when vlan group is not configured.

For ixgb HW both CTRL0.VME and VLE bit in the Tx descriptor need to be set
in order to enable HW acceleration.

Introduced separate functions for enabling/disabling of vlan tag stripping
similar to ixgbe.

CC: Jesse Gross <jesse@nicira.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ixgb/ixgb_main.c |   51 ++++++++++++++++++++++++-----------------
 1 files changed, 30 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index 211a169..2e98506 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -98,6 +98,8 @@ static void ixgb_alloc_rx_buffers(struct ixgb_adapter *, int);
 static void ixgb_tx_timeout(struct net_device *dev);
 static void ixgb_tx_timeout_task(struct work_struct *work);
 
+static void ixgb_vlan_strip_enable(struct ixgb_adapter *adapter);
+static void ixgb_vlan_strip_disable(struct ixgb_adapter *adapter);
 static void ixgb_vlan_rx_register(struct net_device *netdev,
                                   struct vlan_group *grp);
 static void ixgb_vlan_rx_add_vid(struct net_device *netdev, u16 vid);
@@ -1076,6 +1078,8 @@ ixgb_set_multi(struct net_device *netdev)
 
 	if (netdev->flags & IFF_PROMISC) {
 		rctl |= (IXGB_RCTL_UPE | IXGB_RCTL_MPE);
+		/* disable VLAN filtering */
+		rctl &= ~IXGB_RCTL_CFIEN;
 		rctl &= ~IXGB_RCTL_VFE;
 	} else {
 		if (netdev->flags & IFF_ALLMULTI) {
@@ -1084,7 +1088,9 @@ ixgb_set_multi(struct net_device *netdev)
 		} else {
 			rctl &= ~(IXGB_RCTL_UPE | IXGB_RCTL_MPE);
 		}
+		/* enable VLAN filtering */
 		rctl |= IXGB_RCTL_VFE;
+		rctl &= ~IXGB_RCTL_CFIEN;
 	}
 
 	if (netdev_mc_count(netdev) > IXGB_MAX_NUM_MULTICAST_ADDRESSES) {
@@ -1103,6 +1109,12 @@ ixgb_set_multi(struct net_device *netdev)
 
 		ixgb_mc_addr_list_update(hw, mta, netdev_mc_count(netdev), 0);
 	}
+
+	if (netdev->features & NETIF_F_HW_VLAN_RX)
+		ixgb_vlan_strip_enable(adapter);
+	else
+		ixgb_vlan_strip_disable(adapter);
+
 }
 
 /**
@@ -2150,33 +2162,30 @@ static void
 ixgb_vlan_rx_register(struct net_device *netdev, struct vlan_group *grp)
 {
 	struct ixgb_adapter *adapter = netdev_priv(netdev);
-	u32 ctrl, rctl;
 
-	ixgb_irq_disable(adapter);
 	adapter->vlgrp = grp;
+}
 
-	if (grp) {
-		/* enable VLAN tag insert/strip */
-		ctrl = IXGB_READ_REG(&adapter->hw, CTRL0);
-		ctrl |= IXGB_CTRL0_VME;
-		IXGB_WRITE_REG(&adapter->hw, CTRL0, ctrl);
-
-		/* enable VLAN receive filtering */
+static void
+ixgb_vlan_strip_enable(struct ixgb_adapter *adapter)
+{
+	u32 ctrl;
 
-		rctl = IXGB_READ_REG(&adapter->hw, RCTL);
-		rctl &= ~IXGB_RCTL_CFIEN;
-		IXGB_WRITE_REG(&adapter->hw, RCTL, rctl);
-	} else {
-		/* disable VLAN tag insert/strip */
+	/* enable VLAN tag insert/strip */
+	ctrl = IXGB_READ_REG(&adapter->hw, CTRL0);
+	ctrl |= IXGB_CTRL0_VME;
+	IXGB_WRITE_REG(&adapter->hw, CTRL0, ctrl);
+}
 
-		ctrl = IXGB_READ_REG(&adapter->hw, CTRL0);
-		ctrl &= ~IXGB_CTRL0_VME;
-		IXGB_WRITE_REG(&adapter->hw, CTRL0, ctrl);
-	}
+static void
+ixgb_vlan_strip_disable(struct ixgb_adapter *adapter)
+{
+	u32 ctrl;
 
-	/* don't enable interrupts unless we are UP */
-	if (adapter->netdev->flags & IFF_UP)
-		ixgb_irq_enable(adapter);
+	/* disable VLAN tag insert/strip */
+	ctrl = IXGB_READ_REG(&adapter->hw, CTRL0);
+	ctrl &= ~IXGB_CTRL0_VME;
+	IXGB_WRITE_REG(&adapter->hw, CTRL0, ctrl);
 }
 
 static void
-- 
1.7.3.2

Re: [PATCH 04/27] Documentation/networking/igbvf.txt: Update documentation

[Ben Hutchings]

On Fri, 2010-12-10 at 22:16 -0800, Jeff Kirsher wrote:
> Update Intel Wired LAN igbvf documentation.
> 
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
>  Documentation/networking/igbvf.txt |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/networking/igbvf.txt b/Documentation/networking/igbvf.txt
> index 0560281..694817b 100644
> --- a/Documentation/networking/igbvf.txt
> +++ b/Documentation/networking/igbvf.txt
> @@ -58,7 +58,9 @@ Additional Configurations
>    Ethtool
>    -------
>    The driver utilizes the ethtool interface for driver configuration and
> -  diagnostics, as well as displaying statistical information.
> +  diagnostics, as well as displaying statistical information.  Ethtool
> +  version 3.0 or later is required for this functionality, although we
> +  strongly recommend downloading the latest version at:
>  
>    http://sourceforge.net/projects/gkernel.

Do I have to point out every instance of this URL individually?

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [net-next 00/27][pull-request] Intel Wired LAN Driver Updates

[David Miller]

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 10 Dec 2010 22:16:54 -0800

> Here are a batch of fixes and cleanups intended for 2.6.38.
> 
> v2- updated igb.txt and e1000e (patch 27) based on feedback from
>     Ben Hutchings and Joe Perches.
> 
> The following changes since commit:
> 
> commit a5d62a149bb8f5359aff7ed7dce339752fbabfd9
> Author: David S. Miller <davem@davemloft.net>
> Date:   Fri Dec 10 16:49:24 2010 -0800
>   isdn: Fix printed out copy_from_user() return value after previous change
> 
> are available in the git repository at:
> 
>   master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6.git master

Pulled, thanks Jeff.

Re: [PATCH 04/27] Documentation/networking/igbvf.txt: Update documentation

[David Miller]

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 11 Dec 2010 02:45:55 -0800

> I have additional changes for all the docs which I planned on
> submitting next week.  I will update all the URL as well in that
> update.

This makes sense to me, thanks Jeff.

Re: [PATCH 10/27] ixgb: Don't check for vlan group on transmit

[Jesse Gross]

On Fri, Dec 10, 2010 at 10:17 PM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> From: Emil Tantilov <emil.s.tantilov@intel.com>
>
> Based on a patch from Jesse Gross.
>
> Enable vlan tag insertion even when vlan group is not configured.
>
> For ixgb HW both CTRL0.VME and VLE bit in the Tx descriptor need to be set
> in order to enable HW acceleration.
>
> Introduced separate functions for enabling/disabling of vlan tag stripping
> similar to ixgbe.

Thanks for working on this.  However, I don't think that this patch
actually does what it says.

In ixgb_xmit_frame() it's still checking whether adapter->vlgrp is
non-null before inserting a tag, so it will drop tags unless a vlan
group is configured.  Also, since it's not currently possible to
toggle NETIF_F_HW_VLAN_RX, vlan stripping will never get disabled.
This is actually a regression since before vlan stripping would get
disabled if no vlan group was configured.  Now, vlan headers will get
silently dropped if there is no vlan group.

Regardless of that, I still think this is a useful change on the road
towards adopting the new vlan interfaces, the problem is just that
currently it's halfway in between the old and the new.  Given that, it
would obviously be much better to move all the way over the new when
addressing this.

Out of curiosity, is the implication of this that vlan insertion on
transmit and stripping on receive are always configured together?  I
don't have hardware supported by this driver but when I worked on
ixgbe (which is at least superficially similar in this area) I didn't
have any problems configuring them independently.

Thanks.

RE: [PATCH 10/27] ixgb: Don't check for vlan group on transmit

[Tantilov, Emil S]

>-----Original Message-----
>From: Jesse Gross [mailto:jesse@nicira.com]
>Sent: Sunday, December 12, 2010 5:01 PM
>To: Kirsher, Jeffrey T
>Cc: davem@davemloft.net; Tantilov, Emil S; netdev@vger.kernel.org;
>gospo@redhat.com; bphilips@novell.com
>Subject: Re: [PATCH 10/27] ixgb: Don't check for vlan group on transmit
>
>On Fri, Dec 10, 2010 at 10:17 PM, Jeff Kirsher
><jeffrey.t.kirsher@intel.com> wrote:
>> From: Emil Tantilov <emil.s.tantilov@intel.com>
>>
>> Based on a patch from Jesse Gross.
>>
>> Enable vlan tag insertion even when vlan group is not configured.
>>
>> For ixgb HW both CTRL0.VME and VLE bit in the Tx descriptor need to be
>set
>> in order to enable HW acceleration.
>>
>> Introduced separate functions for enabling/disabling of vlan tag
>stripping
>> similar to ixgbe.
>
>Thanks for working on this.  However, I don't think that this patch
>actually does what it says.
>
>In ixgb_xmit_frame() it's still checking whether adapter->vlgrp is
>non-null before inserting a tag, so it will drop tags unless a vlan
>group is configured.  Also, since it's not currently possible to
>toggle NETIF_F_HW_VLAN_RX, vlan stripping will never get disabled.
>This is actually a regression since before vlan stripping would get
>disabled if no vlan group was configured.  Now, vlan headers will get
>silently dropped if there is no vlan group.
I'm sorry. This patch was supposed to include your original patch that 
removed the vlgrp check on Tx. Somehow that didn't make it (I may have generated the patch from the wrong branch).

>Regardless of that, I still think this is a useful change on the road
>towards adopting the new vlan interfaces, the problem is just that
>currently it's halfway in between the old and the new.  Given that, it
>would obviously be much better to move all the way over the new when
>addressing this.
Since this patch is already applied can you submit your change again?

>Out of curiosity, is the implication of this that vlan insertion on
>transmit and stripping on receive are always configured together?  I
>don't have hardware supported by this driver but when I worked on
>ixgbe (which is at least superficially similar in this area) I didn't
>have any problems configuring them independently.

Yes - the design of the original 10GB HW supported in ixgb does not allow 
setting Tx and Rx independently. As you mentioned ixgbe does not have 
this problem.

>
>Thanks.

Thanks,
Emil

Re: [PATCH 10/27] ixgb: Don't check for vlan group on transmit

[Jesse Gross]

On Mon, Dec 13, 2010 at 10:43 AM, Tantilov, Emil S
<emil.s.tantilov@intel.com> wrote:
>>-----Original Message-----
>>From: Jesse Gross [mailto:jesse@nicira.com]
>>Sent: Sunday, December 12, 2010 5:01 PM
>>To: Kirsher, Jeffrey T
>>Cc: davem@davemloft.net; Tantilov, Emil S; netdev@vger.kernel.org;
>>gospo@redhat.com; bphilips@novell.com
>>Subject: Re: [PATCH 10/27] ixgb: Don't check for vlan group on transmit
>>
>>On Fri, Dec 10, 2010 at 10:17 PM, Jeff Kirsher
>><jeffrey.t.kirsher@intel.com> wrote:
>>> From: Emil Tantilov <emil.s.tantilov@intel.com>
>>>
>>> Based on a patch from Jesse Gross.
>>>
>>> Enable vlan tag insertion even when vlan group is not configured.
>>>
>>> For ixgb HW both CTRL0.VME and VLE bit in the Tx descriptor need to be
>>set
>>> in order to enable HW acceleration.
>>>
>>> Introduced separate functions for enabling/disabling of vlan tag
>>stripping
>>> similar to ixgbe.
>>
>>Thanks for working on this.  However, I don't think that this patch
>>actually does what it says.
>>
>>In ixgb_xmit_frame() it's still checking whether adapter->vlgrp is
>>non-null before inserting a tag, so it will drop tags unless a vlan
>>group is configured.  Also, since it's not currently possible to
>>toggle NETIF_F_HW_VLAN_RX, vlan stripping will never get disabled.
>>This is actually a regression since before vlan stripping would get
>>disabled if no vlan group was configured.  Now, vlan headers will get
>>silently dropped if there is no vlan group.
> I'm sorry. This patch was supposed to include your original patch that
> removed the vlgrp check on Tx. Somehow that didn't make it (I may have generated the patch from the wrong branch).
>
>>Regardless of that, I still think this is a useful change on the road
>>towards adopting the new vlan interfaces, the problem is just that
>>currently it's halfway in between the old and the new.  Given that, it
>>would obviously be much better to move all the way over the new when
>>addressing this.
> Since this patch is already applied can you submit your change again?

Sure.  I think it's probably best to just complete the conversion to
the new vlan interfaces, so I went ahead and did that.  It's much
easier now that you've pulled the hardware specific bits out for
enabling/disabling vlan offloading.  I'll send out that patch shortly
- please take a look since I don't have the hardware to test it.

>
>>Out of curiosity, is the implication of this that vlan insertion on
>>transmit and stripping on receive are always configured together?  I
>>don't have hardware supported by this driver but when I worked on
>>ixgbe (which is at least superficially similar in this area) I didn't
>>have any problems configuring them independently.
>
> Yes - the design of the original 10GB HW supported in ixgb does not allow
> setting Tx and Rx independently. As you mentioned ixgbe does not have
> this problem.

OK, thanks for the explanation.

RE: [PATCH 10/27] ixgb: Don't check for vlan group on transmit

[Tantilov, Emil S]

Jesse Gross wrote:
> On Mon, Dec 13, 2010 at 10:43 AM, Tantilov, Emil S
> <emil.s.tantilov@intel.com> wrote:
>>> -----Original Message-----
>>> From: Jesse Gross [mailto:jesse@nicira.com]
>>> Sent: Sunday, December 12, 2010 5:01 PM
>>> To: Kirsher, Jeffrey T
>>> Cc: davem@davemloft.net; Tantilov, Emil S; netdev@vger.kernel.org;
>>> gospo@redhat.com; bphilips@novell.com
>>> Subject: Re: [PATCH 10/27] ixgb: Don't check for vlan group on
>>> transmit 
>>> 
>>> On Fri, Dec 10, 2010 at 10:17 PM, Jeff Kirsher
>>> <jeffrey.t.kirsher@intel.com> wrote:
>>>> From: Emil Tantilov <emil.s.tantilov@intel.com>
>>>> 
>>>> Based on a patch from Jesse Gross.
>>>> 
>>>> Enable vlan tag insertion even when vlan group is not configured.
>>>> 
>>>> For ixgb HW both CTRL0.VME and VLE bit in the Tx descriptor need
>>>> to be set in order to enable HW acceleration.
>>>> 
>>>> Introduced separate functions for enabling/disabling of vlan tag
>>>> stripping similar to ixgbe.
>>> 
>>> Thanks for working on this.  However, I don't think that this patch
>>> actually does what it says. 
>>> 
>>> In ixgb_xmit_frame() it's still checking whether adapter->vlgrp is
>>> non-null before inserting a tag, so it will drop tags unless a vlan
>>> group is configured.  Also, since it's not currently possible to
>>> toggle NETIF_F_HW_VLAN_RX, vlan stripping will never get disabled.
>>> This is actually a regression since before vlan stripping would get
>>> disabled if no vlan group was configured.  Now, vlan headers will
>>> get silently dropped if there is no vlan group.
>> I'm sorry. This patch was supposed to include your original patch
>> that 
>> removed the vlgrp check on Tx. Somehow that didn't make it (I may
>> have generated the patch from the wrong branch). 
>> 
>>> Regardless of that, I still think this is a useful change on the
>>> road towards adopting the new vlan interfaces, the problem is just
>>> that currently it's halfway in between the old and the new.  Given
>>> that, it would obviously be much better to move all the way over
>>> the new when addressing this.
>> Since this patch is already applied can you submit your change again?
> 
> Sure.  I think it's probably best to just complete the conversion to
> the new vlan interfaces, so I went ahead and did that.  It's much
> easier now that you've pulled the hardware specific bits out for
> enabling/disabling vlan offloading.  I'll send out that patch shortly
> - please take a look since I don't have the hardware to test it.

Thanks Jesse!

I'll ask Jeff to pick the patch in his tree and we'll run some tests.

Emil