1. 27 Jan, 2013 4 commits
  2. 18 Jan, 2013 2 commits
  3. 15 Jan, 2013 1 commit
  4. 01 Dec, 2012 1 commit
  5. 09 Oct, 2012 1 commit
  6. 04 May, 2012 1 commit
  7. 02 May, 2012 2 commits
    • Bruce Allan's avatar
      e1000e: fix .ndo_set_rx_mode for 82579 · 69e1e019
      Bruce Allan authored
      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: default avatarBruce Allan <bruce.w.allan@intel.com>
      Tested-by: default avatarJeff Pieper <jeffrey.e.pieper@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
    • Bruce Allan's avatar
      e1000e: workaround EEPROM configuration change on 82579 · 62bc813e
      Bruce Allan authored
      An update to the EEPROM on 82579 will extend a delay in hardware to fix an
      issue with WoL not working after a G3->S5 transition which is unrelated to
      the driver.  However, this extended delay conflicts with nominal operation
      of the device when it is initialized by the driver and after every reset
      of the hardware (i.e. the driver starts configuring the device before the
      hardware is done with it's own configuration work).  The workaround for
      when the driver is in control of the device is to tell the hardware after
      every reset the configuration delay should be the original shorter one.
      Some pre-existing variables are renamed generically to be re-used with
      new register accesses.
      Signed-off-by: default avatarBruce Allan <bruce.w.allan@intel.com>
      Tested-by: default avatarJeff Pieper <jeffrey.e.pieper@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
  8. 27 Apr, 2012 1 commit
    • Bruce Allan's avatar
      e1000e: 82579 potential system hang on stress when ME enabled · bdc125f7
      Bruce Allan authored
      Previously, a workaround was added to address a hardware bug in the
      PCIm2PCI arbiter where a write by the driver of the Transmit/Receive
      Descriptor Tail register could happen concurrently with a write of any
      MAC CSR register by the Manageability Engine (ME) which could cause the
      Tail register to have an incorrect value.  The arbiter is supposed to
      prevent the concurrent writes but there is a bug that can cause the Host
      (driver) access to be acknowledged later than it should.
      After further investigation, it was discovered that a driver write access
      of any MAC CSR register after being idle for some time can be lost when
      ME is accessing a MAC CSR register.  When this happens, no further target
      access is claimed by the MAC which could hang the system.
      The workaround to check bit 24 in the FWSM register (set only when ME is
      accessing a MAC CSR register) and delay for a limited amount of time until
      it is cleared is now done for all driver writes of MAC CSR registers on
      82579 with ME enabled.  In the rare case when the driver is writing the
      Tail register and ME is accessing any MAC CSR register for a duration
      longer than the maximum delay, write the register and verify it has the
      correct value before continuing, otherwise reset the device.
      This patch also moves some pre-existing macros from the hardware-specific
      header file to the more appropriate generic driver header file.
      Signed-off-by: default avatarBruce Allan <bruce.w.allan@intel.com>
      Tested-by: default avatarJeff Pieper <jeffrey.e.pieper@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
  9. 04 Apr, 2012 1 commit
  10. 24 Feb, 2012 2 commits
  11. 26 Jan, 2012 3 commits
  12. 10 Aug, 2011 1 commit
  13. 09 Jun, 2011 2 commits
    • Bruce Allan's avatar
      e1000e: access multiple PHY registers on same page at the same time · 2b6b168d
      Bruce Allan authored
      Doing a PHY page select can take a long time, relatively speaking. This
      can cause a significant delay when updating a number of PHY registers on
      the same page by unnecessarily setting the page for each PHY access. For
      example when going to Sx, all the PHY wakeup registers (WUC, RAR[], MTA[],
      SHRAR[], IP4AT[], IP6AT[], etc.) on 82577/8/9 need to be updated which
      takes a long time which can cause issues when suspending.
      This patch introduces new PHY ops function pointers to allow callers to
      set the page directly and do any number of PHY accesses on that page.
      This feature is currently only implemented for 82577, 82578 and 82579
      PHYs for both the normally addressed registers as well as the special-
      case addressing of the PHY wakeup registers on page 800. For the latter
      registers, the existing function for accessing the wakeup registers has
      been divided up into three- 1) enable access to the wakeup register page,
      2) perform the register access and 3) disable access to the wakeup register
      page. The two functions that enable/disable access to the wakeup register
      page are necessarily available to the caller so that the caller can restore
      the value of the Port Control (a.k.a. Wakeup Enable) register after the
      wakeup register accesses are done.
      All instances of writing to multiple PHY registers on the same page are
      updated to use this new method and to acquire any PHY locking mechanism
      before setting the page and performing the register accesses, and release
      the locking mechanism afterward.
      Some affiliated magic number cleanup is done as well.
      Signed-off-by: default avatarBruce Allan <bruce.w.allan@intel.com>
      Tested-by: default avatarJeff Pieper <jeffrey.e.pieper@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
    • Bruce Allan's avatar
      e1000e: disable far-end loopback mode on ESB2 · d9b24135
      Bruce Allan authored
      The ESB2 LAN includes a debug feature that enables far-end loopback (FELB)
      of the SerDes/Kumeran interface.  This feature is activated when receiving
      a sequence of symbols that includes a reserved codeword.  On a perfect
      link, FELB would never be activated.  In the presence of bit errors, there
      is a very small, but non-zero, probability of FELB being activated.
      If the FELB is activated, the SerDes link becomes non-functional and must
      be reset.  It could also corrupt the switching tables in the switch since
      the ESB2 is transmitting packets with a different source MAC address.
      This patch disables the FELB feature.
      Signed-off-by: default avatarBruce Allan <bruce.w.allan@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
  14. 27 Apr, 2011 1 commit
  15. 11 Mar, 2011 1 commit
  16. 14 Jan, 2011 2 commits
  17. 10 Jan, 2011 1 commit
  18. 22 Sep, 2010 1 commit
  19. 03 Aug, 2010 1 commit
  20. 27 Jul, 2010 1 commit
  21. 18 Jun, 2010 3 commits
  22. 13 May, 2010 4 commits
  23. 13 Jan, 2010 3 commits