1. 12 2月, 2017 1 次提交
  2. 07 12月, 2016 1 次提交
  3. 23 9月, 2016 1 次提交
    • S
      i40evf: Fix link state event handling · 3f341acc
      Sridhar Samudrala 提交于
      Currently disabling the link state from PF via
      	ip link set enp5s0f0 vf 0 state disable
      doesn't disable the CARRIER on the VF.
      
      This patch updates the carrier and starts/stops the tx queues based on the
      link state notification from PF.
      
        PF: enp5s0f0, VF: enp5s2
        #modprobe i40e
        #echo 2 > /sys/class/net/enp5s0f0/device/sriov_numvfs
        #ip link set enp5s2 up
        #ip -d link show enp5s2
        175: enp5s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
            link/ether ea:4d:60:bc:6f:85 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64
        #ip link set enp5s0f0 vf 0 state disable
        #ip -d link show enp5s0f0
        171: enp5s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
            link/ether 68:05:ca:2e:72:68 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64 numtxqueues 72 numrxqueues 72 portid 6805ca2e7268
            vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state disable, trust off
            vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
        #ip -d link show enp5s2
        175: enp5s2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
             link/ether ea:4d:60:bc:6f:85 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64 numtxqueues 16 numrxqueues 16
      Signed-off-by: NSridhar Samudrala <sridhar.samudrala@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      3f341acc
  4. 20 8月, 2016 1 次提交
  5. 28 6月, 2016 1 次提交
  6. 14 5月, 2016 1 次提交
  7. 06 5月, 2016 1 次提交
  8. 28 4月, 2016 1 次提交
  9. 27 4月, 2016 1 次提交
  10. 18 2月, 2016 1 次提交
  11. 04 2月, 2016 1 次提交
    • M
      i40evf: allow channel bonding of VFs · 209dc4da
      Mitch Williams 提交于
      In some modes, bonding would not enslave VF interfaces. This is due to
      bonding calling change_mtu and the immediately calling open. Because of
      the asynchronous nature of the admin queue mechanism, the VF returns
      -EBUSY to the open call, because it knows the previous operation hasn't
      finished yet. This causes bonding to fail with a less-than-useful error
      message.
      
      To fix this, remove the check for pending operations at the beginning of
      open. But this introduces a new bug where the driver will panic on a
      quick close/open cycle. To fix that, we add a new driver state,
      __I40EVF_DOWN_PENDING, that the driver enters when down is called. The
      driver finally transitions to a fully DOWN state when it receives
      confirmation from the PF driver that all the queues are disabled. This
      allows open to complete even if there is a pending mtu change, and
      bonding is finally happy.
      
      Change-ID: I06f4c7e435d5bacbfceaa7c3f209e0ff04be21cc
      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>
      209dc4da
  12. 13 12月, 2015 1 次提交
  13. 03 12月, 2015 1 次提交
  14. 02 12月, 2015 2 次提交
  15. 26 11月, 2015 2 次提交
  16. 15 10月, 2015 1 次提交
  17. 08 10月, 2015 1 次提交
  18. 04 10月, 2015 1 次提交
    • M
      i40evf: don't blow away MAC address · 8552d854
      Mitch Williams 提交于
      Under certain circumstances, we can get an extra VF_RESOURCES message
      from the PF driver at runtime. When this happens, we need to parse it
      because our VSI may have changed out from underneath us, and that will
      affect our relationship with the PF driver.
      
      However, parsing the resources message also blows away our current MAC
      address in the hardware struct, usually with all zeros. When this
      happens, the next time the interface is opened, it will have no MAC
      address and will a) not work and b) complain.
      
      Fix this issue by restoring the current MAC address from the netdev
      struct after we parse the resource message.
      
      Change-ID: I6cd1b624fc20432f81dc901166c8de195b8e0e65
      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>
      8552d854
  19. 23 7月, 2015 4 次提交
  20. 15 4月, 2015 1 次提交
  21. 27 3月, 2015 1 次提交
    • M
      i40evf: delay releasing rings · e284fc88
      Mitch Williams 提交于
      When the VF interface is closed, we cannot immediately free our rings
      and RX buffers, because the hardware hasn't yet stopped accessing this
      memory. This shows up as a panic or memory corruption when the device is
      brought down while under heavy stress.
      
      To fix this, delay releasing resources until we receive acknowledgment
      from the PF driver that the rings have indeed been stopped. Because of
      this delay, we also need to check to make sure that all of our admin
      queue requests have been handled before allowing the device to be
      opened.
      
      Change-ID: I44edd35529ce2fa2a9512437a3a8e6f14ed8ed63
      Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
      Tested-by: NJim Young <james.m.young@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e284fc88
  22. 14 1月, 2015 2 次提交
  23. 06 12月, 2014 1 次提交
    • M
      i40evf: make early init sequence even more robust · 906a6937
      Mitch Williams 提交于
      When multiple VFs attempt to initialize simultaneously, the firmware may
      delay or drop messages. Make the init code more adept at handling these
      situations by a) reinitializing the admin queue if the firmware fails to
      process a request, and b) resending a request if the PF doesn't answer.
      
      Once the request has been sent again, the PF might end up getting both
      requests and send the configuration information to the driver twice.
      This will cause the VF to complain about receiving an unexpected message
      from the PF. Since this is not fatal, reduce the warning level of the
      log messages that are generated in response to this event.
      
      Change-ID: I9370a1a2fde2ad3934fa25ccfd0545edfbbb4805
      Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
      Tested-by: NJim Young <jamesx.m.young@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      906a6937
  24. 21 11月, 2014 2 次提交
    • M
      i40evf: make checkpatch happy · 75a64435
      Mitch Williams 提交于
      This patch is the result of running checkpatch on the i40evf driver with
      the --strict option. The vast majority of changes are adding/removing
      blank lines, aligning function parameters, and correcting over-long
      lines.
      
      The only possible functional change is changing the flags member of the
      adapter structure to be non-volatile. However, according to the kernel
      documentation, this is not necessary and the volatile should be removed.
      
      Change-ID: Ie8c6414800924f529bef831e8845292b970fe2ed
      Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      75a64435
    • M
      i40e: don't overload fields · 1001dc37
      Mitch Williams 提交于
      Overloading the msg_size field in the arq_event_info struct is just a
      bad idea. It leads to repeated bugs when the structure is used in a
      loop, since the input value (buffer size) is overwritten by the output
      value (actual message length).
      
      Fix this by splitting the field into two and renaming to indicate the
      actual function of each field.
      
      Since the arq_event struct has now changed, we need to change the drivers
      to support this. Note that we no longer need to initialize the buffer size
      each time we go through a loop as this value is no longer destroyed by
      arq processing.
      
      In the process, we also fix a bug in i40evf_verify_api_ver where the
      buffer size was not correctly reinitialized each time through the loop.
      
      Change-ID: Ic7f9633cdd6f871f93e698dfb095e29c696f5581
      Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
      Acked-by: NShannon Nelson <shannon.nelson@intel.com>
      Acked-by: NAshish Shah <ashish.n.shah@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      1001dc37
  25. 11 11月, 2014 2 次提交
  26. 01 7月, 2014 1 次提交
    • M
      i40evf: set flags before sending message · fc86a970
      Mitch Williams 提交于
      In some circumstances, the firmware could beat us to the punch, and the
      reply from the PF would come back before we were able to properly modify
      the aq_pending and aq_required flags. This would mess up the flags and
      put the driver in an indeterminate state, much like Schrödinger's cat.
      However, unlike the cat, the driver is definitely dead.
      
      To fix this, simply set the flags before sending the request to the AQ.
      This way, it won't matter if the interrupt comes back too soon.
      
      Change-ID: I9784655e475675ebcb3140cc7f36f4a96aaadce5
      Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      fc86a970
  27. 26 6月, 2014 1 次提交
    • M
      i40evf: return more useful error information · 6a8e93db
      Mitch Williams 提交于
      When verifying the API version (which is the first time the driver
      communicates with the firmware and thus the PF driver), there are many
      ways in which a failure can occur. There may be an error from the
      firmware, there may be unresponsive firmware, there may be an error from
      the PF driver, etc, etc.
      
      Make this function return more useful information, instead of just -EIO.
      Propagate FW errors back to the caller, and log a message if the PF
      sends an invalid reply.
      
      Change-ID: I3e9135a2b80f7acdb855f62f12b2b2668c9a8951
      Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      6a8e93db
  28. 11 6月, 2014 2 次提交
  29. 08 6月, 2014 2 次提交
  30. 05 6月, 2014 1 次提交