From: hanjun.guo@linaro.org (Hanjun Guo)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC part2 PATCH 2/9] ARM64 / ACPI: Prefill cpu possible/present maps and map logical cpu id to APIC id
Date: Wed, 04 Dec 2013 22:21:11 +0800 [thread overview]
Message-ID: <529F3A57.7010306@linaro.org> (raw)
In-Reply-To: <20131203165755.37b07796@alan.etchedpixels.co.uk>
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.
>> + */
>> +void __init prefill_possible_map(void)
> leaking more unprefixed names into the global namespace
prefill_possible_map() will be called in setup_arch() in setup.c,
and should be gloabl, is this incorrect?
Look forward to your advice
Thanks
Hanjun
next prev parent reply other threads:[~2013-12-04 14:21 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-03 16:39 [RFC part2 PATCH 0/9] Using ACPI MADT table to initialise SMP and GIC Hanjun Guo
2013-12-03 16:39 ` [RFC part2 PATCH 1/9] ARM64 / ACPI: Implement core functions for parsing MADT table Hanjun Guo
2013-12-03 16:39 ` [RFC part2 PATCH 2/9] ARM64 / ACPI: Prefill cpu possible/present maps and map logical cpu id to APIC id Hanjun Guo
2013-12-03 16:57 ` One Thousand Gnomes
2013-12-04 14:21 ` Hanjun Guo [this message]
2013-12-04 15:40 ` Rob Herring
2013-12-04 15:47 ` Rob Herring
2013-12-05 13:24 ` Mark Brown
2013-12-05 13:34 ` Hanjun Guo
2013-12-05 23:09 ` Arnd Bergmann
2013-12-09 8:06 ` Hanjun Guo
2013-12-03 16:39 ` [RFC part2 PATCH 3/9] ARM64 / ACPI: Introduce map_gic_id() to get apic id from MADT or _MAT method Hanjun Guo
2013-12-03 16:39 ` [RFC part2 PATCH 4/9] ARM64 / ACPI: Use Parked Address in GIC structure for spin table SMP initialisation Hanjun Guo
2013-12-03 16:39 ` [RFC part2 PATCH 5/9] ACPI: Define ACPI_IRQ_MODEL_GIC needed for arm Hanjun Guo
2013-12-03 16:39 ` [RFC part2 PATCH 6/9] Irqchip / gic: Set as default domain so we can access from ACPI Hanjun Guo
2013-12-03 16:39 ` [RFC part2 PATCH 7/9] irqdomain: Add a new API irq_create_acpi_mapping() Hanjun Guo
2013-12-03 17:25 ` Rob Herring
2013-12-04 15:38 ` Hanjun Guo
2013-12-10 10:06 ` Linus Walleij
2013-12-03 16:39 ` [RFC part2 PATCH 8/9] ACPI / ARM64: Update acpi_register_gsi to register with the core IRQ subsystem Hanjun Guo
2013-12-05 3:48 ` Arnd Bergmann
2013-12-05 14:01 ` Hanjun Guo
2013-12-03 16:39 ` [RFC part2 PATCH 9/9] ACPI / GIC: Initialize GIC using the information in MADT Hanjun Guo
2013-12-03 17:09 ` Rob Herring
2013-12-04 14:58 ` Hanjun Guo
2013-12-03 17:26 ` Marc Zyngier
2013-12-04 15:32 ` Hanjun Guo
2013-12-04 15:50 ` Marc Zyngier
2013-12-05 13:41 ` Hanjun Guo
2013-12-09 18:54 ` Olof Johansson
[not found] <1385999094-3152-1-git-send-email-hanjun.guo@linaro.org>
[not found] ` < 1385999094-3152-3-git-send-email-hanjun.guo@linaro.org>
[not found] ` <1385999094-3152-3-git-send-email-hanjun.guo@linaro.org>
2013-12-10 12:53 ` [RFC part2 PATCH 2/9] ARM64 / ACPI: Prefill cpu possible/present maps and map logical cpu id to APIC id Grant Likely
2013-12-10 15:07 ` Hanjun Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=529F3A57.7010306@linaro.org \
--to=hanjun.guo@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).