From: Hanjun Guo <guohanjun@huawei.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Hanjun Guo <hanjun.guo@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Olof Johansson <olof@lixom.net>,
Grant Likely <grant.likely@linaro.org>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
Arnd Bergmann <arnd@arndb.de>,
Mark Rutland <mark.rutland@arm.com>,
"Graeme Gregory" <graeme.gregory@linaro.org>,
Sudeep Holla <Sudeep.Holla@arm.com>,
"Jon Masters" <jcm@redhat.com>,
Marc Zyngier <marc.zyngier@arm.com>,
Mark Brown <broonie@kernel.org>, Robert Richter <rric@kernel.org>,
Timur Tabi <timur@codeaurora.org>,
Ashwin Chaugule <ashwinc@codeaurora.org>,
<suravee.suthikulpanit@amd.com>, <linux-acpi@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <linaro-acpi@lists.linaro.org>
Subject: Re: [PATCH v9 02/21] ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID
Date: Thu, 5 Mar 2015 15:44:28 +0800 [thread overview]
Message-ID: <54F8095C.4030308@huawei.com> (raw)
In-Reply-To: <1484357.vjmmcyQq4z@vostro.rjw.lan>
On 2015/3/5 6:29, Rafael J. Wysocki wrote:
> On Wednesday, February 25, 2015 04:39:42 PM Hanjun Guo wrote:
>> CPU hardware ID (phys_id) is defined as u32 in structure acpi_processor,
>> but phys_id is used as int in acpi processor driver, so it will lead to
>> some inconsistence for the drivers.
>>
>> Furthermore, to cater for ACPI arch ports that implement 64 bits CPU
>> ids a generic CPU physical id type is required.
>>
>> So introduce typedef u32 phys_cpuid_t for x86 and ia64, and introduce
>> a macro CPU_PHYS_ID_INVALID as (u32)(-1), use phys_cpuid_t when phys_id
>> defined in acpi processor driver, and replace CPU_PHYS_ID_INVALID as -1
>> for phys_id, this will solve the inconsistence in acpi processor driver,
>> and will prepare for the ACPI on ARM64 too.
>>
>> CC: Rafael J Wysocki <rjw@rjwysocki.net>
>> Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
>> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>> [hj: reworked cpu physid map return codes]
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> arch/ia64/include/asm/acpi.h | 4 ++++
>> arch/ia64/kernel/acpi.c | 2 +-
>> arch/x86/include/asm/acpi.h | 4 ++++
>> arch/x86/kernel/acpi/boot.c | 2 +-
>> drivers/acpi/acpi_processor.c | 7 ++++---
>> drivers/acpi/processor_core.c | 30 +++++++++++++++---------------
>> include/acpi/processor.h | 6 +++---
>> include/linux/acpi.h | 2 +-
>> 8 files changed, 33 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/ia64/include/asm/acpi.h b/arch/ia64/include/asm/acpi.h
>> index a1d91ab..ca1f0e4 100644
>> --- a/arch/ia64/include/asm/acpi.h
>> +++ b/arch/ia64/include/asm/acpi.h
>> @@ -34,6 +34,10 @@
>> #include <linux/numa.h>
>> #include <asm/numa.h>
>>
>> +typedef u32 phys_cpuid_t;
>> +
>> +#define CPU_PHYS_ID_INVALID (u32)(-1)
>> +
>> #ifdef CONFIG_ACPI
>> extern int acpi_lapic;
>> #define acpi_disabled 0 /* ACPI always enabled on IA64 */
>> diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
>> index 2c44989..067ef44 100644
>> --- a/arch/ia64/kernel/acpi.c
>> +++ b/arch/ia64/kernel/acpi.c
>> @@ -887,7 +887,7 @@ static int _acpi_map_lsapic(acpi_handle handle, int physid, int *pcpu)
>> }
>>
>> /* wrapper to silence section mismatch warning */
>> -int __ref acpi_map_cpu(acpi_handle handle, int physid, int *pcpu)
>> +int __ref acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, int *pcpu)
>> {
>> return _acpi_map_lsapic(handle, physid, pcpu);
>> }
>> diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
>> index 3a45668..cd788dd 100644
>> --- a/arch/x86/include/asm/acpi.h
>> +++ b/arch/x86/include/asm/acpi.h
>> @@ -32,6 +32,10 @@
>> #include <asm/mpspec.h>
>> #include <asm/realmode.h>
>>
>> +typedef u32 phys_cpuid_t;
>> +
>> +#define CPU_PHYS_ID_INVALID (u32)(-1)
> Can we define those things in one common place instead of having to duplicate
> the definitions for every arch?
As in your reply in patch 14/21, ARM64 will use 64-bit for
phys_cpuid_t.
>
> Also, I'd like to have
>
> static inline bool invalid_cpu_phys_id(phys_cpuid_t phys_id)
> {
> return (int)phys_id < 0;
> }
>
> as that would cover error codes too.
>
> Moreover, why don't you use (phys_cpuid_t)(-1) in the #define? And call is
> PHYS_CPUID_INVALID for that matter (so that the name of the symbol corresponds
> to the name of the type)?
That's pretty fine to me too.
>
>
>> +
>> #ifdef CONFIG_ACPI
>> extern int acpi_lapic;
>> extern int acpi_ioapic;
>> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
>> index 3d525c6..e4f8582 100644
>> --- a/arch/x86/kernel/acpi/boot.c
>> +++ b/arch/x86/kernel/acpi/boot.c
>> @@ -757,7 +757,7 @@ static int _acpi_map_lsapic(acpi_handle handle, int physid, int *pcpu)
>> }
>>
>> /* wrapper to silence section mismatch warning */
>> -int __ref acpi_map_cpu(acpi_handle handle, int physid, int *pcpu)
>> +int __ref acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, int *pcpu)
>> {
>> return _acpi_map_lsapic(handle, physid, pcpu);
>> }
>> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
>> index 1020b1b..e6c7c56 100644
>> --- a/drivers/acpi/acpi_processor.c
>> +++ b/drivers/acpi/acpi_processor.c
>> @@ -170,7 +170,7 @@ static int acpi_processor_hotadd_init(struct acpi_processor *pr)
>> acpi_status status;
>> int ret;
>>
>> - if (pr->phys_id == -1)
>> + if (pr->phys_id == CPU_PHYS_ID_INVALID)
>> return -ENODEV;
>>
>> status = acpi_evaluate_integer(pr->handle, "_STA", NULL, &sta);
>> @@ -215,7 +215,8 @@ static int acpi_processor_get_info(struct acpi_device *device)
>> union acpi_object object = { 0 };
>> struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
>> struct acpi_processor *pr = acpi_driver_data(device);
>> - int phys_id, cpu_index, device_declaration = 0;
>> + phys_cpuid_t phys_id;
>> + int cpu_index, device_declaration = 0;
>> acpi_status status = AE_OK;
>> static int cpu0_initialized;
>> unsigned long long value;
>> @@ -263,7 +264,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
>> }
>>
>> phys_id = acpi_get_phys_id(pr->handle, device_declaration, pr->acpi_id);
>> - if (phys_id < 0)
>> + if (phys_id == CPU_PHYS_ID_INVALID)
>> acpi_handle_debug(pr->handle, "failed to get CPU physical ID.\n");
>> pr->phys_id = phys_id;
>>
>> diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
>> index 7962651..a5547dc 100644
>> --- a/drivers/acpi/processor_core.c
>> +++ b/drivers/acpi/processor_core.c
>> @@ -32,7 +32,7 @@ static struct acpi_table_madt *get_madt_table(void)
>> }
>>
>> static int map_lapic_id(struct acpi_subtable_header *entry,
>> - u32 acpi_id, int *apic_id)
>> + u32 acpi_id, phys_cpuid_t *apic_id)
>> {
>> struct acpi_madt_local_apic *lapic =
>> container_of(entry, struct acpi_madt_local_apic, header);
>> @@ -48,7 +48,7 @@ static int map_lapic_id(struct acpi_subtable_header *entry,
>> }
>>
>> static int map_x2apic_id(struct acpi_subtable_header *entry,
>> - int device_declaration, u32 acpi_id, int *apic_id)
>> + int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id)
>> {
>> struct acpi_madt_local_x2apic *apic =
>> container_of(entry, struct acpi_madt_local_x2apic, header);
>> @@ -65,7 +65,7 @@ static int map_x2apic_id(struct acpi_subtable_header *entry,
>> }
>>
>> static int map_lsapic_id(struct acpi_subtable_header *entry,
>> - int device_declaration, u32 acpi_id, int *apic_id)
>> + int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id)
>> {
>> struct acpi_madt_local_sapic *lsapic =
>> container_of(entry, struct acpi_madt_local_sapic, header);
>> @@ -83,10 +83,10 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
>> return 0;
>> }
>>
>> -static int map_madt_entry(int type, u32 acpi_id)
>> +static phys_cpuid_t map_madt_entry(int type, u32 acpi_id)
>> {
>> unsigned long madt_end, entry;
>> - int phys_id = -1; /* CPU hardware ID */
>> + phys_cpuid_t phys_id = CPU_PHYS_ID_INVALID; /* CPU hardware ID */
>> struct acpi_table_madt *madt;
>>
>> madt = get_madt_table();
>> @@ -117,12 +117,12 @@ static int map_madt_entry(int type, u32 acpi_id)
>> return phys_id;
>> }
>>
>> -static int map_mat_entry(acpi_handle handle, int type, u32 acpi_id)
>> +static phys_cpuid_t map_mat_entry(acpi_handle handle, int type, u32 acpi_id)
>> {
>> struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
>> union acpi_object *obj;
>> struct acpi_subtable_header *header;
>> - int phys_id = -1;
>> + phys_cpuid_t phys_id = CPU_PHYS_ID_INVALID;
>>
>> if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, &buffer)))
>> goto exit;
>> @@ -149,27 +149,27 @@ exit:
>> return phys_id;
>> }
>>
>> -int acpi_get_phys_id(acpi_handle handle, int type, u32 acpi_id)
>> +phys_cpuid_t acpi_get_phys_id(acpi_handle handle, int type, u32 acpi_id)
>> {
>> - int phys_id;
>> + phys_cpuid_t phys_id;
>>
>> phys_id = map_mat_entry(handle, type, acpi_id);
>> - if (phys_id == -1)
>> + if (phys_id == CPU_PHYS_ID_INVALID)
>> phys_id = map_madt_entry(type, acpi_id);
>>
>> return phys_id;
>> }
>>
>> -int acpi_map_cpuid(int phys_id, u32 acpi_id)
>> +int acpi_map_cpuid(phys_cpuid_t phys_id, u32 acpi_id)
>> {
>> #ifdef CONFIG_SMP
>> int i;
>> #endif
>>
>> - if (phys_id == -1) {
>> + if (phys_id == CPU_PHYS_ID_INVALID) {
>> /*
>> * On UP processor, there is no _MAT or MADT table.
>> - * So above phys_id is always set to -1.
>> + * So above phys_id is always set to CPU_PHYS_ID_INVALID.
>> *
>> * BIOS may define multiple CPU handles even for UP processor.
>> * For example,
>> @@ -190,7 +190,7 @@ int acpi_map_cpuid(int phys_id, u32 acpi_id)
>> if (nr_cpu_ids <= 1 && acpi_id == 0)
>> return acpi_id;
>> else
>> - return phys_id;
>> + return -1;
> Can we use a proper error code here?
I'm afraid not. In ACPI processor drivers, -1 will be deemed to
invalid cpu logical number, if we return error code here, we need
to modify multi places of "if (cpu_logical_num == -1)" to
"if (! (cpu_logical_num < 0))" too, so for me, I prefer to keep it as
-1, but I'm open for suggestions.
Thanks
Hanjun
next prev parent reply other threads:[~2015-03-05 7:47 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-25 8:39 [PATCH v9 00/21] Introduce ACPI for ARM64 based on ACPI 5.1 Hanjun Guo
2015-02-25 8:39 ` [PATCH v9 01/21] ACPI / table: Use pr_debug() instead of pr_info() for MADT table scanning Hanjun Guo
2015-03-04 22:33 ` Rafael J. Wysocki
2015-03-05 17:55 ` Olof Johansson
2015-03-06 20:17 ` Grant Likely
2015-03-06 20:31 ` Joe Perches
2015-03-10 2:35 ` Hanjun Guo
2015-02-25 8:39 ` [PATCH v9 02/21] ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID Hanjun Guo
2015-03-04 22:29 ` Rafael J. Wysocki
2015-03-05 7:44 ` Hanjun Guo [this message]
2015-03-05 13:23 ` Rafael J. Wysocki
2015-03-06 6:48 ` Hanjun Guo
2015-03-06 20:19 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 03/21] ACPI: add arm64 to the platforms that use ioremap Hanjun Guo
2015-03-04 22:33 ` Rafael J. Wysocki
2015-03-06 20:20 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 04/21] ARM64: allow late use of early_ioremap Hanjun Guo
2015-03-06 20:24 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 05/21] ARM64 / ACPI: Get RSDP and ACPI boot-time tables Hanjun Guo
2015-03-05 18:10 ` Olof Johansson
2015-03-05 18:51 ` Lorenzo Pieralisi
2015-03-10 8:01 ` Hanjun Guo
2015-03-10 9:32 ` Lorenzo Pieralisi
2015-03-10 11:19 ` Leif Lindholm
2015-03-10 11:36 ` Hanjun Guo
2015-03-06 20:28 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 06/21] ACPI: fix acpi_os_ioremap for arm64 Hanjun Guo
2015-03-04 22:36 ` Rafael J. Wysocki
2015-03-06 20:30 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 07/21] ACPI / sleep: Introduce arm64 specific acpi_sleep.c Hanjun Guo
2015-03-04 22:38 ` Rafael J. Wysocki
2015-03-04 22:49 ` G Gregory
2015-03-04 23:25 ` Rafael J. Wysocki
2015-03-05 0:16 ` Rafael J. Wysocki
2015-03-06 12:36 ` Lorenzo Pieralisi
2015-03-06 20:34 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 08/21] ARM64 / ACPI: Introduce PCI stub functions for ACPI Hanjun Guo
2015-03-06 18:31 ` Lorenzo Pieralisi
2015-03-10 9:21 ` Hanjun Guo
2015-03-06 20:36 ` Grant Likely
2015-03-09 15:01 ` Liviu Dudau
2015-03-10 9:34 ` Hanjun Guo
2015-02-25 8:39 ` [PATCH v9 09/21] ARM64 / ACPI: Introduce early_param "acpi=" to enable/disable ACPI Hanjun Guo
2015-03-05 18:11 ` Olof Johansson
2015-03-06 20:37 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 10/21] ARM64 / ACPI: If we chose to boot from acpi then disable FDT Hanjun Guo
2015-03-05 18:12 ` Olof Johansson
2015-03-06 20:38 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 11/21] ARM64 / ACPI: Get PSCI flags in FADT for PSCI init Hanjun Guo
2015-03-05 18:19 ` Olof Johansson
2015-03-06 20:40 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 12/21] ACPI / table: Print GIC information when MADT is parsed Hanjun Guo
2015-03-04 22:40 ` Rafael J. Wysocki
2015-03-06 18:06 ` Lorenzo Pieralisi
2015-03-06 20:40 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 13/21] ARM64 / ACPI: Parse MADT for SMP initialization Hanjun Guo
2015-03-05 18:49 ` Olof Johansson
2015-03-10 11:33 ` Hanjun Guo
2015-03-07 22:49 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 14/21] ACPI / processor: Make it possible to get CPU hardware ID via GICC Hanjun Guo
2015-03-04 22:46 ` Rafael J. Wysocki
2015-03-05 8:03 ` Hanjun Guo
2015-03-05 11:27 ` Catalin Marinas
2015-03-05 13:13 ` Rafael J. Wysocki
2015-03-05 15:19 ` Catalin Marinas
2015-03-06 6:51 ` Hanjun Guo
2015-03-07 22:52 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 15/21] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi Hanjun Guo
2015-03-04 22:47 ` Rafael J. Wysocki
2015-03-07 23:05 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 16/21] irqchip: Add GICv2 specific ACPI boot support Hanjun Guo
2015-03-04 22:50 ` Rafael J. Wysocki
2015-03-05 9:06 ` Hanjun Guo
2015-03-05 11:53 ` Catalin Marinas
2015-03-06 0:42 ` Rafael J. Wysocki
2015-03-05 8:21 ` Hanjun Guo
2015-03-07 23:14 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 17/21] clocksource / arch_timer: Parse GTDT to initialize arch timer Hanjun Guo
2015-03-07 23:16 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 18/21] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 Hanjun Guo
2015-03-06 17:47 ` Lorenzo Pieralisi
2015-03-10 12:23 ` Hanjun Guo
2015-03-10 14:16 ` Lorenzo Pieralisi
2015-03-07 23:16 ` Grant Likely
2015-02-25 8:39 ` [PATCH v9 19/21] ARM64 / ACPI: Enable ARM64 in Kconfig Hanjun Guo
2015-03-04 22:52 ` Rafael J. Wysocki
2015-03-07 23:17 ` Grant Likely
2015-02-25 8:40 ` [PATCH v9 20/21] Documentation: ACPI for ARM64 Hanjun Guo
2015-02-27 10:53 ` Shannon Zhao
2015-02-27 11:13 ` Shannon Zhao
2015-02-27 11:20 ` Shannon Zhao
2015-02-25 8:40 ` [PATCH v9 21/21] ARM64 / ACPI: additions of ACPI documentation for arm64 Hanjun Guo
2015-02-27 11:22 ` Shannon Zhao
2015-02-27 14:19 ` Hanjun Guo
2015-03-05 18:54 ` Olof Johansson
2015-02-27 3:20 ` [PATCH v9 00/21] Introduce ACPI for ARM64 based on ACPI 5.1 Timur Tabi
2015-02-27 8:37 ` Hanjun Guo
2015-02-27 10:51 ` Shannon Zhao
2015-02-27 8:50 ` Ard Biesheuvel
2015-02-27 10:36 ` Mark Rutland
2015-02-27 21:05 ` Timur Tabi
2015-03-04 23:18 ` Timur Tabi
2015-03-04 22:56 ` Rafael J. Wysocki
2015-03-05 7:03 ` Hanjun Guo
2015-03-05 18:57 ` Olof Johansson
2015-03-06 4:26 ` 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=54F8095C.4030308@huawei.com \
--to=guohanjun@huawei.com \
--cc=Lorenzo.Pieralisi@arm.com \
--cc=Sudeep.Holla@arm.com \
--cc=arnd@arndb.de \
--cc=ashwinc@codeaurora.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=graeme.gregory@linaro.org \
--cc=grant.likely@linaro.org \
--cc=hanjun.guo@linaro.org \
--cc=jcm@redhat.com \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=olof@lixom.net \
--cc=rjw@rjwysocki.net \
--cc=rric@kernel.org \
--cc=suravee.suthikulpanit@amd.com \
--cc=timur@codeaurora.org \
--cc=will.deacon@arm.com \
/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).