1. 29 10月, 2016 1 次提交
    • A
      i40e: Clean up handling of msglevel flags and debug parameter · 5d4ca23e
      Alexander Duyck 提交于
      So the i40e driver had a really convoluted configuration for how to handle
      the debug flags contained in msg_level.  Part of the issue is that the
      driver has its own 32 bit mask that it was using to track a separate set of
      debug features.  From what I can tell it was trying to use the upper 4 bits
      to determine if the value was meant to represent a bit-mask or the numeric
      value provided by debug level.
      
      What this patch does is clean this up by compressing those 4 bits into bit
      31, as a result we just have to perform a check against the value being
      negative to determine if we are looking at a debug level (positive), or a
      debug mask (negative).  The debug level will populate the msg_level, and
      the debug mask will populate the debug_mask in the hardware struct.
      
      I added similar logic for ethtool.  If the value being provided has bit 31
      set we assume the value being provided is a debug mask, otherwise we assume
      it is a msg_enable mask.  For displaying we only provide the msg_enable,
      and if debug_mask is in use we will print it to the dmesg log.
      
      Lastly I removed the debugfs interface.  It is redundant with what we
      already have in ethtool and really doesn't belong anyway.
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      5d4ca23e
  2. 25 9月, 2016 1 次提交
  3. 23 9月, 2016 1 次提交
  4. 22 7月, 2016 1 次提交
    • M
      i40e: refactor Rx filter handling · c3c7ea27
      Mitch Williams 提交于
      Properly track filter adds and deletes so the driver doesn't lose filters
      during resets and up/down cycles. Add a tracking mechanism so that the
      driver knows when to enter and leave promiscuous mode.
      
      Implement a simple state machine so the driver can track the status of
      each filter throughout its lifecycle. Properly manage the overflow promiscuous
      state for the each VSI, and provide a way for the driver to detect when to exit
      overflow promiscuous mode.
      
      Remove all possible default MAC filters that the firmware may have set up so
      that the driver can manage these correctly, particularly when VLANs come into
      play. Remove the LAA flag for filters; instead just send whatever we get through
      set_mac to the firmware as the LAA for wakeup purposes.
      
      Finally, add the state of each filter to debugfs output so we can see what's
      going on inside the driver's pointy little head.
      
      Change-ID: I97c5e366fac2254fa01eaff4f65c0af61dcf2e1f
      Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c3c7ea27
  5. 06 5月, 2016 4 次提交
  6. 06 4月, 2016 1 次提交
  7. 20 2月, 2016 1 次提交
  8. 18 2月, 2016 6 次提交
  9. 17 2月, 2016 1 次提交
  10. 02 12月, 2015 1 次提交
  11. 24 11月, 2015 1 次提交
  12. 23 10月, 2015 1 次提交
  13. 15 10月, 2015 1 次提交
  14. 09 10月, 2015 1 次提交
  15. 30 9月, 2015 2 次提交
  16. 29 9月, 2015 1 次提交
    • A
      i40e: Fix for recursive RTNL lock during PROMISC change · 30e2561b
      Anjali Singhai 提交于
      The sync_vsi_filters function can be called directly under RTNL
      or through the timer subtask without one. This was causing a deadlock.
      
      If sync_vsi_filters is called from a thread which held the lock,
      and in another thread the PROMISC setting got changed we would
      be executing the PROMISC change in the thread which already held
      the lock alongside the other filter update. The PROMISC change
      requires a reset if we are on a VEB, which requires it to be called
      under RTNL.
      
      Earlier the driver would call reset for PROMISC change without
      checking if we were already under RTNL and would try to grab it
      causing a deadlock. This patch changes the flow to see if we are
      already under RTNL before trying to grab it.
      Signed-off-by: NAnjali Singhai Jain <anjali.singhai@intel.com>
      Signed-off-by: NKiran Patil <kiran.patil@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      30e2561b
  17. 23 7月, 2015 1 次提交
  18. 05 6月, 2015 1 次提交
    • A
      i40e: start up in VEPA mode by default · fc60861e
      Anjali Singhai Jain 提交于
      The patch fixes a bug in the default configuration which
      prevented a software bridge loaded on the PF interface from
      working correctly because broadcast packets are incorrectly
      looped back.
      
      Fix the general case, by loading the driver in VEPA mode Until a
      VF or VMDq VSI is added. This way loopback on the Main VSI is
      turned off until needed and can resolve the issue of unnecessary
      reflection for users that do not have VF or VMDq VSIs setup.
      
      The driver must now coordinate the loopback setting for the Flow
      Director (FDIR) VSI to make sure it is in sync with the current
      VEB or VEPA mode setting.
      
      The user can still switch bridge modes from the bridge commands and
      choose to be in VEPA mode with VF VSIs. Because of hardware
      requirements, the call to switch to VEB mode when no VF/VMDqs are
      present will be rejected.
      
      NOTE: This patch uses BIT_ULL as that is preferred going forward,
      a followup patch in the lower priority queue to net-next will fix
      up the remaining 1 << usages.
      
      Change-ID: Ib121ddb18fe4b3c4f52e9deda6fcbeb9105683d1
      Signed-off-by: NAnjali Singhai Jain <anjali.singhai@intel.com>
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NJim Young <james.m.young@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      fc60861e
  19. 15 4月, 2015 1 次提交
  20. 10 3月, 2015 1 次提交
  21. 09 3月, 2015 2 次提交
  22. 26 2月, 2015 1 次提交
  23. 25 2月, 2015 1 次提交
    • N
      i40e: Add support for getlink, setlink ndo ops · 51616018
      Neerav Parikh 提交于
      Add support for bridge offload ndo_ops getlink and setlink to
      enable bridge hardware mode as per the mode set via IFLA_BRIDGE_MODE.
      The support is only enabled in case of a PF VSI and not available for
      any other VSI type.
      
      By default the i40e driver inserts a bridge as part of the bring-up
      when a FDIR type VSI and/or a FCoE VSI is created. This bridge is
      created in VEB mode by default i.e. after creating the bridge using
      "Add VEB" AQ command the loopback for the PF's default VSI is enabled.
      
      The patch adds capability where all the VSIs created as downlink to
      the bridge inherits the loopback property and enables loopback only
      if the uplink bridge is operating in VEB mode.
      Hence, there is no need to explicitly enable loopback as part of
      allocating resources for SR-IOV VFs and call to do that has been
      removed.
      
      In case a user-request is made either via "bridge" utility or using
      the bridge netlink interface that requires to change the hardware
      bridge mode then that would require a PF reset and rebuild of the
      switch hierarchy.
      
      Also update the copyright year.
      
      Change-ID: I4d78fc1c83158efda29ba7be92239b74f75d6d25
      Signed-off-by: NNeerav Parikh <neerav.parikh@intel.com>
      Tested-By: NJim Young <james.m.young@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      51616018
  24. 24 2月, 2015 1 次提交
  25. 16 1月, 2015 1 次提交
  26. 01 1月, 2015 1 次提交
  27. 06 12月, 2014 2 次提交
  28. 18 11月, 2014 1 次提交
  29. 03 11月, 2014 1 次提交