1. 30 4月, 2017 3 次提交
  2. 17 8月, 2016 1 次提交
  3. 14 5月, 2016 1 次提交
  4. 25 2月, 2016 4 次提交
  5. 13 12月, 2015 2 次提交
  6. 26 6月, 2015 5 次提交
  7. 03 6月, 2015 2 次提交
  8. 04 5月, 2015 2 次提交
    • J
      e1000e: fix call to do_div() to use u64 arg · 30544af5
      Jeff Kirsher 提交于
      We were using s64 for lat_ns (latency nano-second value) since in
      our calculations a negative value could be a resultant.  For negative
      values, we then assign lat_ns to be zero, so the value passed to
      do_div() was never negative, but do_div() expects the argument type
      to be u64, so do a cast to resolve a compile warning seen on
      PowerPC.
      
      CC: Yanjiang Jin <yanjiang.jin@windriver.com>
      CC: Yanir Lubetkin <yanirx.lubetkin@intel.com>
      Reported-by: NYanjiang Jin <yanjiang.jin@windriver.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      30544af5
    • A
      e1000e: Cleanup handling of VLAN_HLEN as a part of max frame size · 8084b86d
      Alexander Duyck 提交于
      When the VLAN_HLEN was added to the calculation for the maximum frame size
      there seems to have been a number of issues added to the driver.
      
      The first issue is that in some cases the maximum frame size for a device
      never really reached the actual maximum frame size as the VLAN header
      length was not included the calculation for that value.  As a result some
      parts only supported a maximum frame size of either 1496 in the case of
      parts that didn't support jumbo frames, and 8996 in the case of the parts
      that do.
      
      The second issue is the fact that there were several checks that weren't
      updated so as a result setting an MTU of 1500 was treated as enabling jumbo
      frames as the calculated value was 1522 instead of 1518.  I have addressed
      those by replacing ETH_FRAME_LEN with VLAN_ETH_FRAME_LEN where appropriate.
      
      The final issue was the fact that lowering the MTU below 1500 would cause
      the driver to allocate 2K buffers for the rings.  This is an old issue that
      was fixed several years ago in igb/ixgbe and I am addressing now by just
      replacing == with a <= so that we always just round up to 1522 for anything
      that isn't a jumbo frame.
      
      Fixes: c751a3d5 ("e1000e: Correctly include VLAN_HLEN when changing interface MTU")
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      8084b86d
  9. 06 3月, 2015 1 次提交
  10. 24 2月, 2015 1 次提交
  11. 26 7月, 2014 2 次提交
  12. 21 7月, 2014 1 次提交
  13. 27 5月, 2014 2 次提交
  14. 06 5月, 2014 4 次提交
  15. 23 4月, 2014 1 次提交
  16. 08 3月, 2014 6 次提交
  17. 14 9月, 2013 1 次提交
    • D
      e1000e: fix overrun of PHY RAR array · c3a0dce3
      David Ertman 提交于
      When copying the MAC RAR registers to PHY there is an error in the
      calculation of the rar_entry_count, which causes a write of unknown/
      undefined register space in the MAC to unknown/undefined register space in
      the PHY.
      
      This patch fixes the overrun with writing to the PHY RAR and also fixes the
      ethtool offline register tests so that the correctly addressed registers
      have the appropriate bitmasks for R/W and RO bits for affected parts.
      
      Shawn Rader gets credit for finding and fixing the register overrun.
      Signed-off-by: NDave Ertman <davidx.m.ertman@intel.com>
      CC: Shawn Rader <shawn.t.rader@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c3a0dce3
  18. 28 7月, 2013 1 次提交