1. 03 Oct, 2017 30 commits
  2. 02 Oct, 2017 10 commits
    • David S. Miller's avatar
      Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue · 4efac6ff
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      40GbE Intel Wired LAN Driver Updates 2017-10-02
      
      This series contains updates to i40e and i40evf.
      
      Shannon Nelson fixes an issue where when a machine has more CPUs than
      queue pairs, the counting gets a "little funky" and turns off Flow
      Director.  So to correct it, limit the number of LAN queues initially
      allocated to be sure there are some left for Flow Director and other
      features.
      
      Lihong cleans up dead code by removing a condition check which cannot
      ever be true.
      
      Christophe Jaillet fixes a potential NULL pointer dereference, which
      could happen if kzalloc() fails.
      
      Filip corrects the reporting of supported link modes, which was incorrect
      for some NICs.  Added support for 'ethtool -m' command, which displays
      information about QSFP+ modules.
      
      Mariusz adds functions to read/write the LED registers to control the
      LEDS, instead of accessing the registers directly whenever the LEDs
      need to be controlled.
      
      Jake fixes a regression where we introduced a scheduling while atomic,
      so introduce a separate helper function which will manage its own need
      for the mac_filter_hash_lock.  Also cleaned up the "PF" parameter in
      i40e_vc_disable_vf() since it is never used and is not needed.  Fixed
      a rare case where it is possible that a reset does not occur when
      i40e_vc_disable_vf() is called, so modify i40e_reset_vf() to return a
      bool to indicate whether it reset or not so that i40e_vc_disable_vf()
      can wait until a reset actually occurs.
      
      Alan adds the ability for the VF to request more or less underlying
      allocated queues from the PF.  Fixes the incorrect method for clearing
      the vf_states variable with a NULL assignment, when we should be
      using atomic bitops since we don't actually want to clear all the
      flags.  Fixed a resource leak, where the PF driver fails to inform
      clients of a VF reset because we were incorrectly checking the
      I40E_VF_STATE_PRE_ENABLE bit.
      
      Mitch converts i40evf_map_rings_to_vectors() to a void function since
      it cannot fail and allows us to clean up the checks for the function
      return value.
      
      Scott enables the driver(s) to pass traffic with VLAN tags using the
      802.1ad Ethernet protocol.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4efac6ff
    • Scott Peterson's avatar
      i40e: Stop dropping 802.1ad tags - eth proto 0x88a8 · ab243ec9
      Scott Peterson authored
      Enable i40e to pass traffic with VLAN tags using the 802.1ad ethernet
      protocol ID (0x88a8).
      
      This requires NIC firmware providing version 1.7 of the API. With
      older NIC firmware 802.1ad tagged packets will continue to be dropped.
      
      No VLAN offloads nor RSS are supported for 802.1ad VLANs.
      Signed-off-by: default avatarScott Peterson <scott.d.peterson@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      ab243ec9
    • Alan Brady's avatar
      i40e: fix client notify of VF reset · c53d11f6
      Alan Brady authored
      Currently there is a bug in which the PF driver fails to inform clients
      of a VF reset which then causes clients to leak resources.  The bug
      exists because we were incorrectly checking the I40E_VF_STATE_PRE_ENABLE
      bit.
      
      When a VF is first init we go through a reset to initialize variables
      and allocate resources but we don't want to inform clients of this first
      reset since the client isn't fully enabled yet so we set a state bit
      signifying we're in a "pre-enabled" client state.  During the first
      reset we should be clearing the bit, allowing all following resets to
      notify the client of the reset when the bit is not set.  This patch
      fixes the issue by negating the 'test_and_clear_bit' check to accurately
      reflect the behavior we want.
      Signed-off-by: default avatarAlan Brady <alan.brady@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c53d11f6
    • Alan Brady's avatar
      i40e: fix handling of vf_states variable · 41d0a4d0
      Alan Brady authored
      Currently we inappropriately clear the vf_states variable with a null
      assignment.  This is problematic because we should be using atomic
      bitops on this variable and we don't actually want to clear all the
      flags.  We should just clear the ones we know we want to clear.
      Additionally remove the I40E_VF_STATE_FCOEENA bit because it is no
      longer being used.
      Signed-off-by: default avatarAlan Brady <alan.brady@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      41d0a4d0
    • Mitch Williams's avatar
      i40e: make i40evf_map_rings_to_vectors void · 1b7b7596
      Mitch Williams authored
      This function cannot fail, so why is it returning a value? And why are
      we checking it? Why shouldn't we just make it void? Why is this commit
      message made up of only questions?
      Signed-off-by: default avatarMitch Williams <mitch.a.williams@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      1b7b7596
    • Alan Brady's avatar
      i40evf: Enable VF to request an alternate queue allocation · 5b36e8d0
      Alan Brady authored
      Currently the VF gets a default number of allocated queues from HW on
      init and it could choose to enable or disable those allocated queues.
      This makes it such that the VF can request more or less underlying
      allocated queues from the PF.
      
      First the VF negotiates the number of queues it wants that can be
      supported by the PF and if successful asks for a reset.  During reset
      the PF will reallocate the HW queues for the VF and will then remap the
      new queues.
      Signed-off-by: default avatarAlan Brady <alan.brady@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      5b36e8d0
    • Jacob Keller's avatar
      i40e: ensure reset occurs when disabling VF · d43d60e5
      Jacob Keller authored
      It is possible although rare that we may not reset when
      i40e_vc_disable_vf() is called. This can lead to some weird
      circumstances with some values not being properly set. Modify
      i40e_reset_vf() to return a code indicating whether it reset or not.
      
      Now, i40e_vc_disable_vf() can wait until a reset actually occurs. If it
      fails to free up within a reasonable time frame we'll display a warning
      message.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      d43d60e5
    • Jacob Keller's avatar
      i40e: make use of i40e_vc_disable_vf · f18d2021
      Jacob Keller authored
      Replace i40e_vc_notify_vf_reset and i40e_reset_vf with a call to
      i40e_vc_disable_vf which does this exact thing. This matches similar
      code patterns throughout the driver.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      f18d2021
    • Jacob Keller's avatar
      i40e: drop i40e_pf *pf from i40e_vc_disable_vf() · eeeddbb8
      Jacob Keller authored
      It's never used, and the vf structure could get back to the PF if
      necessary. Lets just drop the extra unneeded parameter.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      eeeddbb8
    • Jacob Keller's avatar
      i40e: don't hold spinlock while resetting VF · ba4e003d
      Jacob Keller authored
      When we refactored handling of the PVID in commit 9af52f60
      ("i40e: use (add|rm)_vlan_all_mac helper functions when changing PVID")
      we introduced a scheduling while atomic regression.
      
      This occurred because we now held the spinlock across a call to
      i40e_reset_vf(), which results in a usleep_range() call that triggers
      a scheduling while atomic bug. This was rare as it only occurred if the
      user configured a VLAN on a VF and also attempted to reconfigure the VF
      from the host system with a port VLAN.
      
      We do need to hold the lock while calling i40e_is_vsi_in_vlan(), but we
      should not be holding it while we reset the VF.
      
      We'll fix this by introducing a separate helper function
      i40e_vsi_has_vlans which checks whether we have a PVID and whether the
      VSI has configured VLANs. This helper function will manage its own need
      for the mac_filter_hash_lock.
      
      Then, we can move the acquiring of the spinlock until after we reset the
      VF, which ensures that we do not sleep while holding the lock.
      
      Using a separate function like this makes the code more clear and is
      easier to read than attempting to release and re-acquire the spinlock
      when we reset the VF.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      ba4e003d