1. 27 1月, 2013 5 次提交
  2. 18 1月, 2013 2 次提交
  3. 16 1月, 2013 5 次提交
  4. 09 1月, 2013 1 次提交
  5. 08 12月, 2012 1 次提交
  6. 04 12月, 2012 1 次提交
    • B
      net/intel: remove __dev* attributes · 9f9a12f8
      Bill Pemberton 提交于
      CONFIG_HOTPLUG is going away as an option.  As result the __dev*
      markings will be going away.
      
      Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
      and __devexit.
      Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
      Cc: Bruce Allan <bruce.w.allan@intel.com>
      Cc: Carolyn Wyborny <carolyn.wyborny@intel.com>
      Cc: Don Skidmore <donald.c.skidmore@intel.com>
      Cc: Greg Rose <gregory.v.rose@intel.com>
      Cc: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
      Cc: Alex Duyck <alexander.h.duyck@intel.com>
      Cc: John Ronciak <john.ronciak@intel.com>
      Cc: Tushar Dave <tushar.n.dave@intel.com>
      Cc: e1000-devel@lists.sourceforge.net
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f9a12f8
  7. 01 12月, 2012 1 次提交
  8. 23 10月, 2012 1 次提交
  9. 11 10月, 2012 1 次提交
    • H
      e1000e: Change wthresh to 1 to avoid possible Tx stalls · 8edc0e62
      Hiroaki SHIMODA 提交于
      This patch originated from Hiroaki SHIMODA but has been modified
      by Intel with some minor cleanups and additional commit log text.
      
      Denys Fedoryshchenko and others reported Tx stalls on e1000e with
      BQL enabled.  Issue was root caused to hardware delays. They were
      introduced because some of the e1000e hardware with transmit
      writeback bursting enabled, waits until the driver does an
      explict flush OR there are WTHRESH descriptors to write back.
      
      Sometimes the delays in question were on the order of seconds,
      causing visible lag for ssh sessions and unacceptable tx
      completion latency, especially for BQL enabled kernels.
      
      To avoid possible Tx stalls, change WTHRESH back to 1.
      
      The current plan is to investigate a method for re-enabling
      WTHRESH while not harming BQL, but those patches will be later
      for net-next if they work.
      
      please enqueue for stable since v3.3 as this bug was introduced in
      commit 3f0cfa3b
      Author: Tom Herbert <therbert@google.com>
      Date:   Mon Nov 28 16:33:16 2011 +0000
      
          e1000e: Support for byte queue limits
      
          Changes to e1000e to use byte queue limits.
      Reported-by: NDenys Fedoryshchenko <denys@visp.net.lb>
      Tested-by: NDenys Fedoryshchenko <denys@visp.net.lb>
      Signed-off-by: NHiroaki SHIMODA <shimoda.hiroaki@gmail.com>
      CC: eric.dumazet@gmail.com
      CC: therbert@google.com
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8edc0e62
  10. 09 10月, 2012 1 次提交
  11. 08 9月, 2012 1 次提交
  12. 31 8月, 2012 5 次提交
  13. 24 8月, 2012 1 次提交
  14. 09 8月, 2012 1 次提交
  15. 14 7月, 2012 1 次提交
  16. 11 7月, 2012 1 次提交
  17. 01 7月, 2012 1 次提交
    • B
      e1000e: remove use of IP payload checksum · 2e1706f2
      Bruce Allan 提交于
      Currently only used when packet split mode is enabled with jumbo frames,
      IP payload checksum (for fragmented UDP packets) is mutually exclusive with
      receive hashing offload since the hardware uses the same space in the
      receive descriptor for the hardware-provided packet checksum and the RSS
      hash, respectively.  Users currently must disable jumbos when receive
      hashing offload is enabled, or vice versa, because of this incompatibility.
      Since testing has shown that IP payload checksum does not provide any real
      benefit, just remove it so that there is no longer a choice between jumbos
      or receive hashing offload but not both as done in other Intel GbE drivers
      (e.g. e1000, igb).
      
      Also, add a missing check for IP checksum error reported by the hardware;
      let the stack verify the checksum when this happens.
      
      CC: stable <stable@vger.kernel.org> [3.4]
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e1706f2
  18. 14 6月, 2012 1 次提交
  19. 06 6月, 2012 1 次提交
  20. 05 5月, 2012 1 次提交
  21. 04 5月, 2012 2 次提交
  22. 03 5月, 2012 3 次提交
  23. 02 5月, 2012 1 次提交
    • B
      e1000e: fix .ndo_set_rx_mode for 82579 · 69e1e019
      Bruce Allan 提交于
      Secondary unicast and multicast addresses are added to the Receive
      Address registers (RAR) for most parts supported by the driver.  For
      82579, there is only one actual RAR and a number of Shared Receive Address
      registers (SHRAR) that are shared among the driver and f/w which can be
      reserved and write-protected by the f/w.  On this device, use the SHRARs
      that are not taken by f/w for the additional addresses.
      
      Add a MAC ops function pointer infrastructure (similar to other MAC
      operations in the driver) for setting RARs, introduce a new rar_set
      function for 82579 and convert the existing code that sets RARs on other
      devices to a generic rar_set function.
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      69e1e019
  24. 01 5月, 2012 1 次提交