1. 03 Oct, 2017 3 commits
    • Jacob Keller's avatar
      fm10k: use generic PM hooks instead of legacy PCIe power hooks · 8249c47c
      Jacob Keller authored
      Replace the PCI specific legacy power management hooks with the new
      generic power management hooks which work properly for both suspend and
      hibernate. The new generic system is better and properly handles the
      lower level PCIe power management rather than forcing the driver to
      handle it.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      8249c47c
    • Jacob Keller's avatar
      fm10k: use spinlock to implement mailbox lock · b4fcd436
      Jacob Keller authored
      Lets not re-invent the locking wheel. Remove our bitlock and use
      a proper spinlock instead.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      b4fcd436
    • Jacob Keller's avatar
      fm10k: prepare_for_reset() when we lose PCIe Link · 0b40f457
      Jacob Keller authored
      If we lose PCIe link, such as when an unannounced PFLR event occurs, or
      when a device is surprise removed, we currently detach the device and
      close the netdev. This unfortunately leaves a lot of things still
      active, such as the msix_mbx_pf IRQ, and Tx/Rx resources.
      
      This can cause problems because the register reads will return
      potentially invalid values which may result in unknown driver behavior.
      
      Begin the process of resetting using fm10k_prepare_for_reset(), much in
      the same way as the suspend and resume cycle does. This will attempt to
      shutdown as much as possible, in order to prevent possible issues.
      
      A naive implementation for this has issues, because there are now
      multiple flows calling the reset logic and setting a reset bit. This
      would cause problems, because the "re-attach" routine might call
      fm10k_handle_reset() prior to the reset actually finishing. Instead,
      we'll add state bits to indicate which flow actually initiated the
      reset.
      
      For the general reset flow, we'll assume that if someone else is
      resetting that we do not need to handle it at all, so it does not need
      its own state bit. For the suspend case, we will simply issue a warning
      indicating that we are attempting to recover from this case when
      resuming.
      
      For the detached subtask, we'll simply refuse to re-attach until we've
      actually initiated a reset as part of that flow.
      
      Finally, we'll stop attempting to manage the mailbox subtask when we're
      detached, since there's nothing we can do if we don't have a PCIe
      address.
      
      Overall this produces a much cleaner shutdown and recovery cycle for
      a PCIe surprise remove event.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0b40f457
  2. 02 Oct, 2017 37 commits