linux-toradex.git/drivers/pci/remove.c, branch v4.4.93

PCI: Export symbols required for loadable host driver modules

2015-04-08T19:17:10+00:00

Export the following symbols so they can be referenced by a PCI host bridge
driver compiled as a kernel loadable module:

  pci_common_swizzle
  pci_create_root_bus
  pci_stop_root_bus
  pci_remove_root_bus
  pci_assign_unassigned_bus_resources
  pci_fixup_irqs

Signed-off-by: Ray Jui 
Signed-off-by: Bjorn Helgaas 
Acked-by: Arnd Bergmann

Revert "PCI: Remove from bus_list and release resources in pci_release_dev()"

2014-02-01T18:24:31+00:00

Revert commit ef83b0781a73 "PCI: Remove from bus_list and release
resources in pci_release_dev()" that made some nasty race conditions
become possible.  For example, if a Thunderbolt link is unplugged
and then replugged immediately, the pci_release_dev() resulting from
the hot-remove code path may be racing with the hot-add code path
which after that commit causes various kinds of breakage to happen
(up to and including a hard crash of the whole system).

Moreover, the problem that commit ef83b0781a73 attempted to address
cannot happen any more after commit 8a4c5c329de7 "PCI: Check parent
kobject in pci_destroy_dev()", because pci_destroy_dev() will now
return immediately if it has already been executed for the given
device.

Note, however, that the invocation of msi_remove_pci_irq_vectors()
removed by commit ef83b0781a73 from pci_free_resources() along with
the other changes made by it is not added back because of subsequent
code changes depending on that modification.

Fixes: ef83b0781a73 (PCI: Remove from bus_list and release resources in pci_release_dev())
Reported-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Linus Torvalds

PCI: Check parent kobject in pci_destroy_dev()

2014-01-15T17:34:13+00:00

If pci_stop_and_remove_bus_device() is run concurrently for a device and
its parent bridge via remove_callback(), both code paths attempt to acquire
pci_rescan_remove_lock.  If the child device removal acquires it first,
there will be no problems.  However, if the parent bridge removal acquires
it first, it will eventually execute pci_destroy_dev() for the child
device, but that device object will not be freed yet due to the reference
held by the concurrent child removal.  Consequently, both
pci_stop_bus_device() and pci_remove_bus_device() will be executed for that
device unnecessarily and pci_destroy_dev() will see a corrupted list head
in that object.  Moreover, an excess put_device() will be executed for that
device in that case which may lead to a use-after-free in the final
kobject_put() done by sysfs_schedule_callback_work().

To avoid that problem, make pci_destroy_dev() check if the device's parent
kobject is NULL, which only happens after device_del() has already run for
it.  Make pci_destroy_dev() return immediately whithout doing anything in
that case.

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Bjorn Helgaas

PCI: Add global pci_lock_rescan_remove()

2014-01-14T00:49:49+00:00

There are multiple PCI device addition and removal code paths that may be
run concurrently with the generic PCI bus rescan and device removal that
can be triggered via sysfs.  If that happens, it may lead to multiple
different, potentially dangerous race conditions.

The most straightforward way to address those problems is to run
the code in question under the same lock that is used by the
generic rescan/remove code in pci-sysfs.c.  To prepare for those
changes, move the definition of the global PCI remove/rescan lock
to probe.c and provide global wrappers, pci_lock_rescan_remove()
and pci_unlock_rescan_remove(), allowing drivers to manipulate
that lock.  Also provide pci_stop_and_remove_bus_device_locked()
for the callers of pci_stop_and_remove_bus_device() who only need
to hold the rescan/remove lock around it.

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Bjorn Helgaas

PCI: Remove from bus_list and release resources in pci_release_dev()

2013-12-18T20:53:40+00:00

Previously we removed the pci_dev from the bus_list and released its
resources in pci_destroy_dev().  But that's too early: it's possible to
call pci_destroy_dev() twice for the same device (e.g., via sysfs), and
that will cause an oops when we try to remove it from bus_list the second
time.

We should remove it from the bus_list only when the last reference to the
pci_dev has been released, i.e., in pci_release_dev().

[bhelgaas: changelog]
Signed-off-by: Yinghai Lu 
Signed-off-by: Bjorn Helgaas

PCI: Use device_release_driver() in pci_stop_root_bus()

2013-12-18T20:53:36+00:00

To be consistent with 4bff6749905d ("PCI: Move device_del() from
pci_stop_dev() to pci_destroy_dev()", this changes pci_stop_root_bus()
to use device_release_driver() instead of device_del().

This also changes pci_remove_root_bus() to use device_unregister()
instead of put_device() so it corresponds with the device_register()
call in pci_create_root_bus().

[bhelgaas: changelog]
Signed-off-by: Yinghai Lu 
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki

PCI: Move device_del() from pci_stop_dev() to pci_destroy_dev()

2013-12-18T20:53:32+00:00

After commit bcdde7e221a8 (sysfs: make __sysfs_remove_dir() recursive)
I'm seeing traces analogous to the one below in Thunderbolt testing:

WARNING: CPU: 3 PID: 76 at /scratch/rafael/work/linux-pm/fs/sysfs/group.c:214 sysfs_remove_group+0x59/0xe0()
 sysfs group ffffffff81c6c500 not found for kobject '0000:08'
 Modules linked in: ...
 CPU: 3 PID: 76 Comm: kworker/u16:7 Not tainted 3.13.0-rc1+ #76
 Hardware name: Acer Aspire S5-391/Venus    , BIOS V1.02 05/29/2012
 Workqueue: kacpi_hotplug acpi_hotplug_work_fn
  0000000000000009 ffff8801644b9ac8 ffffffff816b23bf 0000000000000007
  ffff8801644b9b18 ffff8801644b9b08 ffffffff81046607 ffff88016925b800
  0000000000000000 ffffffff81c6c500 ffff88016924f928 ffff88016924f800
 Call Trace:
  [] dump_stack+0x4e/0x71
  [] warn_slowpath_common+0x87/0xb0
  [] warn_slowpath_fmt+0x41/0x50
  [] ? sysfs_get_dirent_ns+0x6f/0x80
  [] sysfs_remove_group+0x59/0xe0
  [] dpm_sysfs_remove+0x3b/0x50
  [] device_del+0x58/0x1c0
  [] device_unregister+0x48/0x60
  [] pci_remove_bus+0x6e/0x80
  [] pci_remove_bus_device+0x38/0x110
  [] pci_remove_bus_device+0x4d/0x110
  [] pci_stop_and_remove_bus_device+0x19/0x20
  [] disable_slot+0x20/0xe0
  [] acpiphp_check_bridge+0xa8/0xd0
  [] hotplug_event+0x17d/0x220
  [] hotplug_event_work+0x30/0x70
  [] acpi_hotplug_work_fn+0x18/0x24
  [] process_one_work+0x261/0x450
  [] worker_thread+0x21e/0x370
  [] ? rescuer_thread+0x300/0x300
  [] kthread+0xd2/0xe0
  [] ? flush_kthread_worker+0x70/0x70
  [] ret_from_fork+0x7c/0xb0
  [] ? flush_kthread_worker+0x70/0x70

(Mika Westerberg sees them too in his tests).

Some investigation documented in kernel bug #65281 led me to the
conclusion that the source of the problem is the device_del() in
pci_stop_dev() as it now causes the sysfs directory of the device to be
removed recursively along with all of its subdirectories.  That includes
the sysfs directory of the device's subordinate bus (dev->subordinate) and
its "power" group.

Consequently, when pci_remove_bus() is called for dev->subordinate in
pci_remove_bus_device(), it calls device_unregister(&bus->dev), but at this
point the sysfs directory of bus->dev doesn't exist any more and its
"power" group doesn't exist either.  Thus, when dpm_sysfs_remove() called
from device_del() tries to remove that group, it triggers the above
warning.

That indicates a logical mistake in the design of
pci_stop_and_remove_bus_device(), which causes bus device objects to be
left behind their parents (bridge device objects) and can be fixed by
moving the device_del() from pci_stop_dev() into pci_destroy_dev(), so
pci_remove_bus() can be called for the device's subordinate bus before the
device itself is unregistered from the hierarchy.  Still, the driver, if
any, should be detached from the device in pci_stop_dev(), so use
device_release_driver() directly from there.

References: https://bugzilla.kernel.org/show_bug.cgi?id=65281#c6
Reported-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Bjorn Helgaas

PCI: Fix whitespace, capitalization, and spelling errors

2013-11-14T18:28:18+00:00

Fix whitespace, capitalization, and spelling errors.  No functional change.
I know "busses" is not an error, but "buses" was more common, so I used it
consistently.

Signed-off-by: Marta Rybczynska  (pci_reset_bridge_secondary_bus())
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki

PCI: Add pcibios hooks for adding and removing PCI buses

2013-04-12T21:38:25+00:00

On ACPI-based platforms, the pci_slot driver creates PCI slot devices
according to information from ACPI tables by registering an ACPI PCI
subdriver.  The ACPI PCI subdriver will only be called when creating/
destroying PCI root buses, and it won't be called when hot-plugging
P2P bridges.  It may cause stale PCI slot devices after hot-removing
a P2P bridge if that bridge has associated PCI slots.  And the acpiphp
driver has the same issue too.

This patch introduces two hook points into the PCI core, which will
be invoked when creating/destroying PCI buses for PCI host and P2P
bridges.  They could be used to setup/destroy platform dependent stuff
in a unified way, both at boot time and for PCI hotplug operations.

Signed-off-by: Jiang Liu 
Signed-off-by: Yijing Wang 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Yinghai Lu 
Cc: "Rafael J. Wysocki" 
Cc: Toshi Kani 
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Myron Stowe

PCI: When removing bus, always remove legacy files & unregister

2013-04-12T20:57:02+00:00

We always call device_register() and pci_create_legacy_files() for a
new bus before handing out the "struct pci_bus *".  Therefore, there's
no possiblity of removing the bus with pci_remove_bus() before those
calls have been made, so we don't need to check "bus->is_added" before
calling pci_remove_legacy_files() and device_unregister().

[bhelgaas: changelog]
Signed-off-by: Jiang Liu 
Signed-off-by: Yijing Wang 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Yinghai Lu 
Cc: "Rafael J. Wysocki" 
Cc: Toshi Kani