On Mon, Feb 26, 2018 at 04:21:12PM +0300, Mika Westerberg wrote:
> Following PCIehp mark the unplugged PCI devices disconnected. This makes
> sure PCI core code leaves the now missing hardware registers alone.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> ---
> drivers/pci/hotplug/acpiphp_glue.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
> index 5efa21cdddc9..0aef35ee665a 100644
> --- a/drivers/pci/hotplug/acpiphp_glue.c
> +++ b/drivers/pci/hotplug/acpiphp_glue.c
> @@ -651,6 +651,11 @@ static void trim_stale_devices(struct pci_dev *dev)
> alive = pci_device_is_present(dev);
>
> if (!alive) {
> + pci_dev_set_disconnected(dev, NULL);
> + if (pci_has_subordinate(dev))
> + pci_walk_bus(dev->subordinate, pci_dev_set_disconnected,
> + NULL);
I hate this pci_dev_set_disconnected() thing and hope to remove it
someday. It's racy and adds additional states that are hard to
manage, e.g., "device has been removed and will not respond to PCI
accesses, but pci_dev_set_disconnected() hasn't been called yet". If
we can handle that case (and we should), we shouldn't need
pci_dev_set_disconnected().
But I guess I accepted it other places, so now I have to accept it
here.
I do wonder whether it should be factored into a
"pci_disconnect_dev()" that does both the device itself and the bus
walk.
And I wonder whether that should be called form
pci_stop_and_remove_bus_device(), since some callers do this and
others don't.
> +
> pci_stop_and_remove_bus_device(dev);
> if (adev)
> acpi_bus_trim(adev);
> --
> 2.16.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
