[8/8] PCI, ACPI: remove acpi_root_driver in reserse order

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(-)

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