diff mbox

[V3,1/3] x86/ioapic: Support hot-removal of IOAPICs present during boot

Message ID 1465378364-5982-1-git-send-email-rui.y.wang@intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Wang, Rui Y June 8, 2016, 9:32 a.m. UTC
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(-)

Comments

Thomas Gleixner June 10, 2016, 12:57 p.m. UTC | #1
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-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rafael J. Wysocki June 10, 2016, 1:56 p.m. UTC | #2
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-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bjorn Helgaas June 10, 2016, 4:43 p.m. UTC | #3
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-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Wang, Rui Y June 12, 2016, 6:06 a.m. UTC | #4
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-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bjorn Helgaas June 16, 2016, 5:09 p.m. UTC | #5
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-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Wang, Rui Y June 22, 2016, 7:13 a.m. UTC | #6
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-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bjorn Helgaas June 22, 2016, 2:53 p.m. UTC | #7
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-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Wang, Rui Y June 24, 2016, 3:18 p.m. UTC | #8
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-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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