On Thu, Sep 27, 2012 at 2:11 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > aka stop acpi root driver in this sequence: acpiphp, iommu, ioapic. > > Signed-off-by: Yinghai Lu <yinghai@xxxxxxxxxx> > --- > drivers/acpi/pci_root.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c > index a27cbb57..012f40d 100644 > --- a/drivers/acpi/pci_root.c > +++ b/drivers/acpi/pci_root.c > @@ -672,7 +672,7 @@ static int acpi_pci_root_remove(struct acpi_device *device, int type) > pci_stop_root_bus(root->bus); > > mutex_lock(&acpi_pci_root_lock); > - list_for_each_entry(driver, &acpi_pci_drivers, node) > + list_for_each_entry_reverse(driver, &acpi_pci_drivers, node) > if (driver->remove) > driver->remove(root); This seems sort of OK just because we call the ->add() methods in forward order, so it is symmetric to call the ->remove() methods in reverse order. But I'm uncomfortable with using this as a way to enforce ->remove() ordering across acpiphp, iommu, and ioapic. That seems fragile. What are the dependencies between these drivers that require this ordering? > mutex_unlock(&acpi_pci_root_lock); > -- > 1.7.7 > -- 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
