PCI: Probe for device reset support during enumeration
authorBjorn Helgaas <bhelgaas@google.com>
Fri, 16 Feb 2018 16:55:38 +0000 (10:55 -0600)
committerBjorn Helgaas <helgaas@kernel.org>
Fri, 16 Feb 2018 16:55:38 +0000 (10:55 -0600)
commit5b0764cac9f1b70a6704b0e546be67c24cc05517
tree58bb18762472c5df1c9de1c5b2a5e57c5102b14d
parent7928b2cbe55b2a410a0f5c1f154610059c57b1b2
PCI: Probe for device reset support during enumeration

Previously we called pci_probe_reset_function() in this path:

  pci_sysfs_init                              # late_initcall
    for_each_pci_dev(dev)
      pci_create_sysfs_dev_files(dev)
        pci_create_capabilities_sysfs(dev)
          pci_probe_reset_function
            pci_dev_specific_reset
            pcie_has_flr
              pcie_capability_read_dword

pci_sysfs_init() is a late_initcall, and a driver may have already claimed
one of these devices and enabled runtime power management for it, so the
device could already be in D3 by the time we get to pci_sysfs_init().

The device itself should respond to the config read even while it's in
D3hot, but if an upstream bridge is also in D3hot, the read won't even
reach the device because the bridge won't forward it downstream to the
device.  If the bridge is a PCIe port, it should complete the read as an
Unsupported Request, which may be reported to the CPU as an exception or as
invalid data.

Avoid this case by probing for reset support from pci_init_capabilities(),
before a driver can claim the device.  The device may be in D3hot, but any
bridges leading to it should be in D0, so the device's config space should
be fully accessible at that point.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
drivers/pci/pci-sysfs.c
drivers/pci/probe.c