| Message ID | 1348733519-24684-9-git-send-email-yinghai@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Bjorn Helgaas |
| Headers | show |
On Thu, Sep 27, 2012 at 2:11 AM, Yinghai Lu <yinghai@kernel.org> wrote: > aka stop acpi root driver in this sequence: acpiphp, iommu, ioapic. > > Signed-off-by: Yinghai Lu <yinghai@kernel.org> > --- > 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-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 28, 2012 at 4:46 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: > On Thu, Sep 27, 2012 at 2:11 AM, Yinghai Lu <yinghai@kernel.org> wrote: >> aka stop acpi root driver in this sequence: acpiphp, iommu, ioapic. >> >> Signed-off-by: Yinghai Lu <yinghai@kernel.org> >> --- >> 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? ioapic should come at first, and iommu and last is acpiphp. iommu will check if intr-mapping is corresponding to ioapic controller number. also dmar controller will need one normal irq without intr-remapping for error handling. need to use link sequence in Makefile to make sure iommu come at first. -Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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); mutex_unlock(&acpi_pci_root_lock);
aka stop acpi root driver in this sequence: acpiphp, iommu, ioapic. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/acpi/pci_root.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)