Re: [Patch v4 12/16] x86, irq, ACPI: Implement interface to support ACPI based IOAPIC hot-addition
From: Thomas Gleixner
Date: Tue Sep 09 2014 - 08:20:57 EST
On Thu, 28 Aug 2014, Jiang Liu wrote:
> EXPORT_SYMBOL(acpi_register_ioapic);
> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> index 6e67af0c5f99..b286461cabf9 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -3851,7 +3851,13 @@ static int bad_ioapic_register(int idx)
>
> static int find_free_ioapic_entry(void)
> {
> - return nr_ioapics;
> + int idx;
> +
> + for (idx = 0; idx < MAX_IO_APICS; idx++)
> + if (ioapics[idx].nr_registers == 0)
> + return idx;
> +
> + return MAX_IO_APICS;
> }
>
> int mp_register_ioapic(int id, u32 address, u32 gsi_base,
> @@ -3867,8 +3873,15 @@ int mp_register_ioapic(int id, u32 address, u32 gsi_base,
> }
> for_each_ioapic(ioapic)
> if (ioapics[ioapic].mp_config.apicaddr == address) {
> - pr_warn("address 0x%x conflicts with IOAPIC%d\n",
> - address, ioapic);
> + /*
> + * IOAPIC unit may also be visible in PCI scope.
> + * When ioapic PCI driver's probe() is called,
> + * the IOAPIC unit may have already been initialized
> + * at boot time.
> + */
> + if (!ioapic_initialized)
> + pr_warn("address 0x%x conflicts with IOAPIC%d\n",
> + address, ioapic);
Hmm. This smells fishy. Why do we allow multiple initializations of
the same IOAPIC in the first place. Either it's done via ACPI or via
PCI, but not both.
> return -EEXIST;
> }
>
> @@ -3918,6 +3931,14 @@ int mp_register_ioapic(int id, u32 address, u32 gsi_base,
> ioapics[idx].irqdomain = NULL;
> ioapics[idx].irqdomain_cfg = *cfg;
>
> + if (ioapic_initialized) {
I have a hard time to understand this conditional. Why can't we do
that unconditionally?
> + if (mp_irqdomain_create(idx)) {
> + clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
> + return -ENOMEM;
> + }
> + alloc_ioapic_saved_registers(idx);
> + }
> +
> if (gsi_cfg->gsi_end >= gsi_top)
> gsi_top = gsi_cfg->gsi_end + 1;
> if (nr_ioapics <= idx)
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/