| Message ID | 1465378364-5982-1-git-send-email-rui.y.wang@intel.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Wed, 8 Jun 2016, Rui Wang wrote: > v3: Previous versions break mips. This version fixes it. > > IOAPICs present during system boot aren't added to ioapic_list, > thus are unable to be hot-removed. Fix it by calling > acpi_ioapic_add() during root bus enumeration. Who will pick that one up? I already took 2/3 of this series as they are independent. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday, June 10, 2016 02:57:52 PM Thomas Gleixner wrote: > On Wed, 8 Jun 2016, Rui Wang wrote: > > > v3: Previous versions break mips. This version fixes it. > > > > IOAPICs present during system boot aren't added to ioapic_list, > > thus are unable to be hot-removed. Fix it by calling > > acpi_ioapic_add() during root bus enumeration. > > Who will pick that one up? I already took 2/3 of this series as they are > independent. I can pick it up. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 08, 2016 at 05:32:44PM +0800, Rui Wang wrote: > v3: Previous versions break mips. This version fixes it. > > IOAPICs present during system boot aren't added to ioapic_list, > thus are unable to be hot-removed. Fix it by calling > acpi_ioapic_add() during root bus enumeration. > > Signed-off-by: Rui Wang <rui.y.wang@intel.com> > --- > drivers/acpi/internal.h | 2 -- > drivers/acpi/ioapic.c | 7 ++++--- > drivers/acpi/pci_root.c | 2 +- > drivers/pci/setup-bus.c | 7 ++++++- > include/linux/acpi.h | 3 +++ > 5 files changed, 14 insertions(+), 7 deletions(-) > > diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h > index 9bb0773..bb567a7 100644 > --- a/drivers/acpi/internal.h > +++ b/drivers/acpi/internal.h > @@ -40,10 +40,8 @@ int acpi_sysfs_init(void); > void acpi_container_init(void); > void acpi_memory_hotplug_init(void); > #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC > -int acpi_ioapic_add(struct acpi_pci_root *root); > int acpi_ioapic_remove(struct acpi_pci_root *root); > #else > -static inline int acpi_ioapic_add(struct acpi_pci_root *root) { return 0; } > static inline int acpi_ioapic_remove(struct acpi_pci_root *root) { return 0; } > #endif > #ifdef CONFIG_ACPI_DOCK > diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c > index ccdc8db..0f272e2 100644 > --- a/drivers/acpi/ioapic.c > +++ b/drivers/acpi/ioapic.c > @@ -189,16 +189,17 @@ exit: > return AE_OK; > } > > -int acpi_ioapic_add(struct acpi_pci_root *root) > +int acpi_ioapic_add(acpi_handle root_handle) > { > acpi_status status, retval = AE_OK; > > - status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root->device->handle, > + status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root_handle, > UINT_MAX, handle_ioapic_add, NULL, > - root->device->handle, (void **)&retval); > + root_handle, (void **)&retval); > > return ACPI_SUCCESS(status) && ACPI_SUCCESS(retval) ? 0 : -ENODEV; > } > +EXPORT_SYMBOL_GPL(acpi_ioapic_add); > > int acpi_ioapic_remove(struct acpi_pci_root *root) > { > diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c > index ae3fe4e..53f5965 100644 > --- a/drivers/acpi/pci_root.c > +++ b/drivers/acpi/pci_root.c > @@ -614,7 +614,7 @@ static int acpi_pci_root_add(struct acpi_device *device, > if (hotadd) { > pcibios_resource_survey_bus(root->bus); > pci_assign_unassigned_root_bus_resources(root->bus); > - acpi_ioapic_add(root); > + acpi_ioapic_add(root->device->handle); > } > > pci_lock_rescan_remove(); > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c > index 55641a3..0658921 100644 > --- a/drivers/pci/setup-bus.c > +++ b/drivers/pci/setup-bus.c > @@ -25,6 +25,7 @@ > #include <linux/ioport.h> > #include <linux/cache.h> > #include <linux/slab.h> > +#include <linux/acpi.h> > #include "pci.h" > > unsigned int pci_flags; > @@ -1779,8 +1780,12 @@ void __init pci_assign_unassigned_resources(void) > { > struct pci_bus *root_bus; > > - list_for_each_entry(root_bus, &pci_root_buses, node) > + list_for_each_entry(root_bus, &pci_root_buses, node) { > pci_assign_unassigned_root_bus_resources(root_bus); > +#ifdef CONFIG_X86 > + acpi_ioapic_add(ACPI_HANDLE(root_bus->bridge)); > +#endif This seems like a strange place to call acpi_ioapic_add(). Your object is to call acpi_ioapic_add() during root bus enumeration. I assume we *can't* call acpi_ioapic_add() from acpi_pci_root_add() at boot time, for some reason you'll explain. But is there a reason we have to call it from pci_assign_unassigned_resources() (where it requires an ifdef) instead of from pcibios_assign_resources(), which is already x86-specific? In acpi_pci_root_add(), we have this: acpi_pci_root_add(...) { ... if (hotadd) acpi_ioapic_add(root); So the obvious question is why don't we just remove the "if (hotadd)" and call acpi_ioapic_add() always. I'm sure the reason is some ordering problem, but we need a comment in acpi_pci_root_add() about why the obvious solution doesn't work. > + } > } > > void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge) > diff --git a/include/linux/acpi.h b/include/linux/acpi.h > index 288fac5..3ed22df 100644 > --- a/include/linux/acpi.h > +++ b/include/linux/acpi.h > @@ -262,6 +262,9 @@ int acpi_unmap_cpu(int cpu); > > #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC > int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr); > +int acpi_ioapic_add(acpi_handle root); > +#else > +static inline int acpi_ioapic_add(acpi_handle root) { return 0; } > #endif > > int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base); > -- > 1.8.3.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday, June 11, 2016 12:43 AM, Bjorn Helgaas wrote: > On Wed, Jun 08, 2016 at 05:32:44PM +0800, Rui Wang wrote: > > @@ -1779,8 +1780,12 @@ void __init > > pci_assign_unassigned_resources(void) > > { > > struct pci_bus *root_bus; > > > > - list_for_each_entry(root_bus, &pci_root_buses, node) > > + list_for_each_entry(root_bus, &pci_root_buses, node) { > > pci_assign_unassigned_root_bus_resources(root_bus); > > +#ifdef CONFIG_X86 > > + acpi_ioapic_add(ACPI_HANDLE(root_bus->bridge)); > > +#endif > > This seems like a strange place to call acpi_ioapic_add(). Your object is to call > acpi_ioapic_add() during root bus enumeration. > > I assume we *can't* call acpi_ioapic_add() from acpi_pci_root_add() at boot > time, for some reason you'll explain. But is there a reason we have to call it > from pci_assign_unassigned_resources() (where it requires an ifdef) instead > of from pcibios_assign_resources(), which is already x86-specific? > > In acpi_pci_root_add(), we have this: > > acpi_pci_root_add(...) > { > ... > if (hotadd) > acpi_ioapic_add(root); > > So the obvious question is why don't we just remove the "if (hotadd)" > and call acpi_ioapic_add() always. > > I'm sure the reason is some ordering problem, but we need a comment in > acpi_pci_root_add() about why the obvious solution doesn't work. > Hi Bjorn, Yes it's an ording issue. acpi_ioapic_add() and also ioapic_insert_resources() have to be later than pci initialization in order to deal with IOAPICs mapped on a PCI BAR. There's a comment about this inside pcibios_resource_survey() above ioapic_insert_resources(). We can also add a comment inside acpi_pci_root_add(), though. And yes calling acpi_ioapic_add() in pcibios_assign_resources() doesn't require ifdef CONFIG_X86. But it'll require a loop to iterate through the root buses, and call acpi_ioapic_add() within the loop. pci_assign_unassigned_resources() already has that loop. Do you still prefer adding it to pcibios_assign_resources() ? Regards, Rui -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jun 12, 2016 at 02:06:09PM +0800, Rui Wang wrote: > On Saturday, June 11, 2016 12:43 AM, Bjorn Helgaas wrote: > > On Wed, Jun 08, 2016 at 05:32:44PM +0800, Rui Wang wrote: > > > @@ -1779,8 +1780,12 @@ void __init > > > pci_assign_unassigned_resources(void) > > > { > > > struct pci_bus *root_bus; > > > > > > - list_for_each_entry(root_bus, &pci_root_buses, node) > > > + list_for_each_entry(root_bus, &pci_root_buses, node) { > > > pci_assign_unassigned_root_bus_resources(root_bus); > > > +#ifdef CONFIG_X86 > > > + acpi_ioapic_add(ACPI_HANDLE(root_bus->bridge)); > > > +#endif > > > > This seems like a strange place to call acpi_ioapic_add(). Your object is to call > > acpi_ioapic_add() during root bus enumeration. > > > > I assume we *can't* call acpi_ioapic_add() from acpi_pci_root_add() at boot > > time, for some reason you'll explain. But is there a reason we have to call it > > from pci_assign_unassigned_resources() (where it requires an ifdef) instead > > of from pcibios_assign_resources(), which is already x86-specific? > > > > In acpi_pci_root_add(), we have this: > > > > acpi_pci_root_add(...) > > { > > ... > > if (hotadd) > > acpi_ioapic_add(root); > > > > So the obvious question is why don't we just remove the "if (hotadd)" > > and call acpi_ioapic_add() always. > > > > I'm sure the reason is some ordering problem, but we need a comment in > > acpi_pci_root_add() about why the obvious solution doesn't work. > > Yes it's an ording issue. acpi_ioapic_add() and also ioapic_insert_resources() > have to be later than pci initialization in order to deal with IOAPICs mapped > on a PCI BAR. There's a comment about this inside pcibios_resource_survey() > above ioapic_insert_resources(). We can also add a comment inside > acpi_pci_root_add(), though. > > And yes calling acpi_ioapic_add() in pcibios_assign_resources() doesn't require > ifdef CONFIG_X86. But it'll require a loop to iterate through the root buses, > and call acpi_ioapic_add() within the loop. pci_assign_unassigned_resources() > already has that loop. Do you still prefer adding it to > pcibios_assign_resources() ? ioapic_insert_resources() is x86-specific, but I'm not sure why; it seems like it does things that should be applicable to ia64 as well. acpi_ioapic_add() is not x86-specific, and it is called from acpi_pci_root_add() for the hot-add case. You're adding an x86-xpecific call in pci_assign_unassigned_resources(). Why should the hot-add case be for all arches, but the boot-time case only for x86? -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday, June 17, 2016 1:10 AM, Bjorn Helgaas wrote: > ioapic_insert_resources() is x86-specific, but I'm not sure why; it seems > like it does things that should be applicable to ia64 as well. > > acpi_ioapic_add() is not x86-specific, and it is called from > acpi_pci_root_add() for the hot-add case. You're adding an x86-xpecific call > in pci_assign_unassigned_resources(). Why should the hot-add case be for > all arches, but the boot-time case only for x86? Hi Bjorn, It turns out that IOAPIC hotplug has not been pursued on ia64. There were demos showing CPU sockets online/offline on ia64 but the CPUs had no IIO, thus no IOAPIC hotplug. So to answer the first question: ioapic_insert_resources() is x86-specific because it's inserting what has been setup in io_apic_init_mappings() which, through mpc_ioapic_addr(), is capable of handling both the static case (acpi_parse_ioapic(), etc.) and the hotplug case (acpi_ioapic_add()). But on ia64, there's only the static case through acpi_parse_iosapic(), no need for the hotplug case yet. To answer the second question: acpi_ioapic_add() is in effect x86-specific, because it's an empty function when CONFIG_ACPI_HOTPLUG_IOAPIC isn't defined. And CONFIG_ACPI_HOTPLUG_IOAPIC depends on CONFIG_X86_IO_APIC (see drivers/acpi/Kconfig). This was introduced in c183619b6 (x86/irq, ACPI: Implement ACPI driver to support IOAPIC hotplug). That commit shows the dependency. I'll send a newer version with comments explaining these. Thanks Rui -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 22, 2016 at 03:13:32PM +0800, Rui Wang wrote: > On Friday, June 17, 2016 1:10 AM, Bjorn Helgaas wrote: > > ioapic_insert_resources() is x86-specific, but I'm not sure why; it seems > > like it does things that should be applicable to ia64 as well. > > > > acpi_ioapic_add() is not x86-specific, and it is called from > > acpi_pci_root_add() for the hot-add case. You're adding an x86-xpecific call > > in pci_assign_unassigned_resources(). Why should the hot-add case be for > > all arches, but the boot-time case only for x86? > > Hi Bjorn, > > It turns out that IOAPIC hotplug has not been pursued on ia64. There were > demos showing CPU sockets online/offline on ia64 but the CPUs had no IIO, > thus no IOAPIC hotplug. That doesn't mean we need to write code that's gratuitously x86-specific. > So to answer the first question: > ioapic_insert_resources() is x86-specific because it's inserting what has > been setup in io_apic_init_mappings() which, through mpc_ioapic_addr(), is > capable of handling both the static case (acpi_parse_ioapic(), etc.) and the > hotplug case (acpi_ioapic_add()). But on ia64, there's only the static > case through acpi_parse_iosapic(), no need for the hotplug case yet. ioapic_insert_resources() inserts IOAPIC resources on x86. Where are IOSAPIC resources inserted on ia64? > To answer the second question: > acpi_ioapic_add() is in effect x86-specific, because it's an empty function > when CONFIG_ACPI_HOTPLUG_IOAPIC isn't defined. And CONFIG_ACPI_HOTPLUG_IOAPIC > depends on CONFIG_X86_IO_APIC (see drivers/acpi/Kconfig). This was introduced > in c183619b6 (x86/irq, ACPI: Implement ACPI driver to support IOAPIC hotplug). > That commit shows the dependency. > > I'll send a newer version with comments explaining these. I'd rather have code that is not x86-specific than comments explaining why the code is x86-specific. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, June 22, 2016 10:54 PM Bjorn Helgaas wrote: > On Wed, Jun 22, 2016 at 03:13:32PM +0800, Rui Wang wrote: > > On Friday, June 17, 2016 1:10 AM, Bjorn Helgaas wrote: > > > ioapic_insert_resources() is x86-specific, but I'm not sure why; it > > > seems like it does things that should be applicable to ia64 as well. > > > > > > acpi_ioapic_add() is not x86-specific, and it is called from > > > acpi_pci_root_add() for the hot-add case. You're adding an > > > x86-xpecific call in pci_assign_unassigned_resources(). Why should > > > the hot-add case be for all arches, but the boot-time case only for x86? > > > > Hi Bjorn, > > > > It turns out that IOAPIC hotplug has not been pursued on ia64. There > > were demos showing CPU sockets online/offline on ia64 but the CPUs had > > no IIO, thus no IOAPIC hotplug. > > That doesn't mean we need to write code that's gratuitously x86-specific. > > > So to answer the first question: > > ioapic_insert_resources() is x86-specific because it's inserting what > > has been setup in io_apic_init_mappings() which, through > > mpc_ioapic_addr(), is capable of handling both the static case > > (acpi_parse_ioapic(), etc.) and the hotplug case (acpi_ioapic_add()). > > But on ia64, there's only the static case through acpi_parse_iosapic(), no > need for the hotplug case yet. > > ioapic_insert_resources() inserts IOAPIC resources on x86. Where are > IOSAPIC resources inserted on ia64? > I'm not sure. Its physical address from MADT is parsed in acpi_parse_iosapic() and ioremap()'d in iosapic_init(). Only the virtual address is recorded. The physical address doesn't seem to be recorded and inserted explicitly. But it could be in a "_CRS" and gets inserted implicitly. The iosapic on ia64 uses its own data structures very different from the ioapic on x86. I think it's hard to unify them using a common set of functions, without rewriting the whole framework. Thanks Rui -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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/internal.h b/drivers/acpi/internal.h index 9bb0773..bb567a7 100644 --- a/drivers/acpi/internal.h +++ b/drivers/acpi/internal.h @@ -40,10 +40,8 @@ int acpi_sysfs_init(void); void acpi_container_init(void); void acpi_memory_hotplug_init(void); #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC -int acpi_ioapic_add(struct acpi_pci_root *root); int acpi_ioapic_remove(struct acpi_pci_root *root); #else -static inline int acpi_ioapic_add(struct acpi_pci_root *root) { return 0; } static inline int acpi_ioapic_remove(struct acpi_pci_root *root) { return 0; } #endif #ifdef CONFIG_ACPI_DOCK diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c index ccdc8db..0f272e2 100644 --- a/drivers/acpi/ioapic.c +++ b/drivers/acpi/ioapic.c @@ -189,16 +189,17 @@ exit: return AE_OK; } -int acpi_ioapic_add(struct acpi_pci_root *root) +int acpi_ioapic_add(acpi_handle root_handle) { acpi_status status, retval = AE_OK; - status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root->device->handle, + status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root_handle, UINT_MAX, handle_ioapic_add, NULL, - root->device->handle, (void **)&retval); + root_handle, (void **)&retval); return ACPI_SUCCESS(status) && ACPI_SUCCESS(retval) ? 0 : -ENODEV; } +EXPORT_SYMBOL_GPL(acpi_ioapic_add); int acpi_ioapic_remove(struct acpi_pci_root *root) { diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c index ae3fe4e..53f5965 100644 --- a/drivers/acpi/pci_root.c +++ b/drivers/acpi/pci_root.c @@ -614,7 +614,7 @@ static int acpi_pci_root_add(struct acpi_device *device, if (hotadd) { pcibios_resource_survey_bus(root->bus); pci_assign_unassigned_root_bus_resources(root->bus); - acpi_ioapic_add(root); + acpi_ioapic_add(root->device->handle); } pci_lock_rescan_remove(); diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 55641a3..0658921 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -25,6 +25,7 @@ #include <linux/ioport.h> #include <linux/cache.h> #include <linux/slab.h> +#include <linux/acpi.h> #include "pci.h" unsigned int pci_flags; @@ -1779,8 +1780,12 @@ void __init pci_assign_unassigned_resources(void) { struct pci_bus *root_bus; - list_for_each_entry(root_bus, &pci_root_buses, node) + list_for_each_entry(root_bus, &pci_root_buses, node) { pci_assign_unassigned_root_bus_resources(root_bus); +#ifdef CONFIG_X86 + acpi_ioapic_add(ACPI_HANDLE(root_bus->bridge)); +#endif + } } void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge) diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 288fac5..3ed22df 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -262,6 +262,9 @@ int acpi_unmap_cpu(int cpu); #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr); +int acpi_ioapic_add(acpi_handle root); +#else +static inline int acpi_ioapic_add(acpi_handle root) { return 0; } #endif int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base);
v3: Previous versions break mips. This version fixes it. IOAPICs present during system boot aren't added to ioapic_list, thus are unable to be hot-removed. Fix it by calling acpi_ioapic_add() during root bus enumeration. Signed-off-by: Rui Wang <rui.y.wang@intel.com> --- drivers/acpi/internal.h | 2 -- drivers/acpi/ioapic.c | 7 ++++--- drivers/acpi/pci_root.c | 2 +- drivers/pci/setup-bus.c | 7 ++++++- include/linux/acpi.h | 3 +++ 5 files changed, 14 insertions(+), 7 deletions(-)