1. 13 Jan, 2015 1 commit
  2. 06 Dec, 2014 1 commit
    • Mitch Williams's avatar
      i40evf: make early init sequence even more robust · 906a6937
      Mitch Williams authored
      
      
      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: default avatarMitch Williams <mitch.a.williams@intel.com>
      Tested-by: default avatarJim Young <jamesx.m.young@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      906a6937
  3. 20 Nov, 2014 2 commits
    • Mitch Williams's avatar
      i40evf: make checkpatch happy · 75a64435
      Mitch Williams authored
      
      
      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: default avatarMitch Williams <mitch.a.williams@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      75a64435
    • Mitch Williams's avatar
      i40e: don't overload fields · 1001dc37
      Mitch Williams authored
      
      
      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: default avatarMitch Williams <mitch.a.williams@intel.com>
      Acked-by: default avatarShannon Nelson <shannon.nelson@intel.com>
      Acked-by: default avatarAshish Shah <ashish.n.shah@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      1001dc37
  4. 11 Nov, 2014 2 commits
  5. 01 Jul, 2014 1 commit
    • Mitch Williams's avatar
      i40evf: set flags before sending message · fc86a970
      Mitch Williams authored
      
      
      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: default avatarMitch Williams <mitch.a.williams@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      fc86a970
  6. 26 Jun, 2014 1 commit
    • Mitch Williams's avatar
      i40evf: return more useful error information · 6a8e93db
      Mitch Williams authored
      
      
      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: default avatarMitch Williams <mitch.a.williams@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      6a8e93db
  7. 11 Jun, 2014 2 commits
  8. 08 Jun, 2014 2 commits
  9. 05 Jun, 2014 1 commit
  10. 21 May, 2014 1 commit
  11. 21 Feb, 2014 1 commit
  12. 13 Feb, 2014 1 commit
    • Mitch Williams's avatar
      i40evf: refactor reset handling · ef8693eb
      Mitch Williams authored
      
      
      Respond better to a VF reset event. When a reset is signaled by the
      PF, or detected by the watchdog task, prevent the watchdog from
      processing admin queue requests, and schedule the reset task.
      
      In the reset task, wait first for the reset to start, then for it to
      complete, then reinit the driver.
      
      If the reset never appears to complete after a long, long time (>10
      seconds is possible depending on what's going on with the PF driver),
      then set a flag to indicate that PF communications have failed.
      
      If this flag is set, check for the reset to complete in the watchdog,
      and  attempt to do a full reinitialization of the driver from scratch.
      
      With these changes the VF driver correctly handles a PF reset event
      while running on bare metal, or in a VM.
      
      Also update copyrights.
      
      Change-ID: I93513efd0b50523a8345e7f6a33a5e4f8a2a5996
      Signed-off-by: default avatarMitch Williams <mitch.a.williams@intel.com>
      Signed-off-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: default avatarSibai Li <sibai.li@intel.com>
      Signed-off-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef8693eb
  13. 31 Dec, 2013 1 commit
    • Greg Rose's avatar
      i40evf: virtual channel interface · 62683ab5
      Greg Rose authored
      
      
      This PCI-E SR-IOV virtual function (VF) driver is dependant upon the
      physical function (PF) driver (i40e) for nearly all of its hardware
      configuration. Requests from the VF driver are passed to the PF using
      the hardware's Admin Queue.
      
      This patch contains the functionality for communicating with the PF
      driver. Because of the delay inherent in this communications channel,
      most of the replies from the PF driver are handled asynchronously. The
      exceptions are the "send API version" and "get VF config" messages,
      which busy-wait because they are done so early during init that
      interrupts are not yet configured.
      Signed-off-by: default avatarMitch Williams <mitch.a.williams@intel.com>
      Signed-off-by: default avatarGreg Rose <gregory.v.rose@intel.com>
      Tested-by: default avatarSibai Li <sibai.li@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      62683ab5