summaryrefslogtreecommitdiff
path: root/drivers/pci
diff options
context:
space:
mode:
authorJacob Keller <jacob.e.keller@intel.com>2016-04-01 23:17:34 (GMT)
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>2016-04-21 06:06:23 (GMT)
commit3417415c3a86d6bae8bfee495ce634f4d24e16b8 (patch)
tree5c8366cf6aab4c968a35ae2656fcf41e0c7a335c /drivers/pci
parenta7a7783adabc3cc7599f7dbf97fcc3b0d44087b7 (diff)
downloadlinux-3417415c3a86d6bae8bfee495ce634f4d24e16b8.tar.xz
fm10k: do not disable PCI device in fm10k_io_error_detected
fm10k_io_error_detected() does not need to call pci_disable_device(). In the cases where the reset needs to occur, the stack flow will result in calling fm10k_remove() which already disables the PCI device. If we leave the pci_disable_device(), we result in a warning about disabling an already disabled device. Many PCI drivers do call pci_disable_device() in their .error_detected() routines, but it does not appear to be required. In addition, these drivers have a check "is_pci_enabled()" call in their remove routines, which is how they chose to handle the duplicate device disable. This seems incorrect, since the PCI device structure is reference counted. It is very possible that the reference count for the PCI device could be greater than 1. In this case, you would remove the PCI device within the error_detected routine, reducing count to 1, then remove it again in the remove function, reducing it to zero. This would result in yet another disable somewhere else failing. Thus, we shouldn't be using is_pci_enabled() to check for this issue. Instead, just remove the extraneous pci_device_disable() found within the error_detected routine. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Diffstat (limited to 'drivers/pci')
0 files changed, 0 insertions, 0 deletions