1. 08 8月, 2018 1 次提交
  2. 01 5月, 2018 1 次提交
  3. 28 4月, 2018 1 次提交
  4. 24 3月, 2018 1 次提交
  5. 20 3月, 2018 3 次提交
  6. 15 3月, 2018 1 次提交
  7. 27 1月, 2018 2 次提交
  8. 24 1月, 2018 2 次提交
  9. 11 1月, 2018 2 次提交
  10. 22 11月, 2017 2 次提交
  11. 01 11月, 2017 2 次提交
  12. 18 10月, 2017 1 次提交
  13. 14 10月, 2017 1 次提交
  14. 10 10月, 2017 1 次提交
  15. 03 10月, 2017 4 次提交
  16. 30 9月, 2017 1 次提交
  17. 28 8月, 2017 2 次提交
  18. 21 6月, 2017 1 次提交
  19. 02 6月, 2017 1 次提交
  20. 20 4月, 2017 1 次提交
  21. 29 3月, 2017 1 次提交
  22. 28 3月, 2017 1 次提交
  23. 19 2月, 2017 1 次提交
  24. 12 2月, 2017 1 次提交
  25. 07 12月, 2016 3 次提交
  26. 03 12月, 2016 2 次提交
    • J
      i40e: set broadcast promiscuous mode for each active VLAN · 435c084a
      Jacob Keller 提交于
      A previous workaround added to ensure receipt of all broadcast frames
      incorrectly set the broadcast promiscuous mode unconditionally
      regardless of active VLAN status.
      
      Replace this partial workaround with a complete solution that sets the
      broadcast promiscuous filters in i40e_sync_vsi_filters. This new method
      sets the promiscuous mode based on when broadcast filters are added or
      removed.
      
      I40E_VLAN_ANY will request a broadcast filter for all VLANs, (as we're
      in untagged mode) while a broadcast filter on a specific VLAN will only
      request broadcast for that VLAN.
      
      Thus, we restore addition of broadcast filter to the array, but we add
      special handling for these such that they enable the broadcast
      promiscuous mode instead of being sent as regular filters.
      
      The end result is that we will correctly receive all broadcast packets
      (even those with a *source* address equal to the broadcast address) but
      will not receive packets for which we don't have an active VLAN filter.
      
      Change-ID: I7d0585c5cec1a5bf55bf533b42e5e817d5db6a2d
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      435c084a
    • H
      i40e: Pass unknown PHY type for unknown PHYs · e586bb66
      Henry Tieman 提交于
      The PHY type value for unrecognized PHYs and cables was changed
      based on firmware version number. Newer hardware use lower firmware
      version numbers and this was causing some PHYs to be identified
      as type 0x16 instead of 0xe (unknown).
      
      Without this patch, newer card will incorrectly identify unknown
      PHYs and cables.
      
      This change adds hardware type to the check for firmware version
      so the PHY type is reported correctly.
      
      Change-ID: I0723cbfd263c76fc73ff1a5275d1639051376c9a
      Signed-off-by: NHenry Tieman <henry.w.tieman@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e586bb66