]> git.baikalelectronics.ru Git - kernel.git/commit
PCI: Do not treat EPROBE_DEFER as device attach failure
authorLukas Wunner <lukas@wunner.de>
Mon, 2 May 2016 18:48:31 +0000 (13:48 -0500)
committerBjorn Helgaas <bhelgaas@google.com>
Mon, 2 May 2016 18:49:11 +0000 (13:49 -0500)
commitffbf2e297f098d685393fb1247c490c49d1670fd
tree4e5a2801caa1e2396f86e01d21cd119239bf6532
parent575e21bec561b2d6f2e736ddc003df50b2f620df
PCI: Do not treat EPROBE_DEFER as device attach failure

Linux 4.5 introduced a behavioral change in device probing during the
suspend process with commit ec08f37e2217 ("PM / sleep: prohibit devices
probing during suspend/hibernation"): It defers device probing during the
entire suspend process, starting from the prepare phase and ending with the
complete phase.  A rule existed before that "we rely on subsystems not to
do any probing once a device is suspended" but it is enforced only now
(Alan Stern, https://lkml.org/lkml/2015/9/15/908).

This resulted in a WARN splat if a PCI device (e.g., Thunderbolt) is
plugged in while the system is asleep: Upon waking up, pciehp_resume()
discovers new devices in the resume phase and immediately tries to bind
them to a driver.  Since probing is now deferred, device_attach() returns
-EPROBE_DEFER, which provoked a WARN in pci_bus_add_device().

Linux 4.6-rc1 aggravates the situation with commit 3014c8eca91e ("PCI:
Check device_attach() return value always"): If device_attach() returns a
negative value, pci_bus_add_device() now removes the sysfs and procfs
entries for the device and pci_bus_add_devices() subsequently locks up with
a BUG.  Even with the BUG fixed we're still in trouble because the device
remains on the deferred probing list even though its sysfs and procfs
entries are gone and its children won't be added.

Fix by not interpreting -EPROBE_DEFER as failure.  The device will be
probed eventually (through device_unblock_probing() in dpm_complete()) and
there is proper locking in place to avoid races (e.g., if devices are
unplugged again und thus deleted from the system before deferred probing
happens, I have tested this).  Also, those functions which dereference
dev->driver (e.g. pci_pm_*()) do contain proper NULL pointer checks.  So it
seems safe to ignore -EPROBE_DEFER.

Fixes: 3014c8eca91e ("PCI: Check device_attach() return value always")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
drivers/pci/bus.c