Messages in this thread |  | | Date | Wed, 4 Dec 2013 09:40:04 -0600 | Subject | Re: [RFC part2 PATCH 2/9] ARM64 / ACPI: Prefill cpu possible/present maps and map logical cpu id to APIC id | From | Rob Herring <> |
| |
On Wed, Dec 4, 2013 at 8:21 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote: > On 2013年12月04日 00:57, One Thousand Gnomes wrote: >>> >>> diff --git a/drivers/acpi/plat/arm-core.c b/drivers/acpi/plat/arm-core.c >>> index 45ff625..8527ecc 100644 >>> --- a/drivers/acpi/plat/arm-core.c >>> +++ b/drivers/acpi/plat/arm-core.c >>> @@ -58,6 +58,13 @@ EXPORT_SYMBOL(acpi_pci_disabled); >>> */ >>> static u64 acpi_lapic_addr __initdata; >>> +/* available_cpus here means enabled cpu in MADT */ >>> +int available_cpus; >>> + >>> +/* Map logic cpu id to physical GIC id. */ >>> +int arm_cpu_to_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = -1 }; >>> +int boot_cpu_apic_id = -1; >>> + >> >> static ? >> >> Really shouldn't be leaking names like "available_cpus" out of ACPI into >> the global namespace > > > Ok, will update in next version. > > > >>> +#ifdef CONFIG_SMP >>> + if (available_cpus == 0) { >>> + pr_info(PREFIX "Found 0 CPUs; assuming 1\n"); >>> + /* FIXME: should be the real GIC id read from hardware */ >>> + arm_cpu_to_apicid[available_cpus] = 0; >>> + available_cpus = 1; /* We've got at least one of >>> these */ >>> + } >>> +#endif >> >> Isn't this true uniprocessor (by definition in fact) > > > This code is intend to handle some buggy firmware I think.
Really? We have production firmware already that we need to work-around? That's impressive given there is no production h/w.
Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |