From: fengchengwen <fengchengwen@huawei.com>
To: Jeremy Linton <jeremy.linton@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
"Rafael J . Wysocki" <rafael@kernel.org>
Cc: <punit.agrawal@oss.qualcomm.com>, <guohanjun@huawei.com>,
<suzuki.poulose@arm.com>, <ryan.roberts@arm.com>,
<chenl311@chinatelecom.cn>, <masahiroy@kernel.org>,
<wangyuquan1236@phytium.com.cn>, <anshuman.khandual@arm.com>,
<heinrich.schuchardt@canonical.com>, <Eric.VanTassell@amd.com>,
<jonathan.cameron@huawei.com>, <wangzhou1@hisilicon.com>,
<wanghuiqiang@huawei.com>, <liuyonglong@huawei.com>,
<linux-pci@vger.kernel.org>, <linux-doc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<loongarch@lists.linux.dev>, <linux-riscv@lists.infradead.org>,
<xen-devel@lists.xenproject.org>, <linux-acpi@vger.kernel.org>,
<linux-perf-users@vger.kernel.org>, <stable@vger.kernel.org>
Subject: Re: [PATCH v7 1/3] ACPI: Refactor get_acpi_id_for_cpu() to acpi_get_cpu_uid() on non-x86
Date: Wed, 18 Mar 2026 12:04:13 +0800 [thread overview]
Message-ID: <0744ee77-78ee-4e3d-9f0d-e8fe44be1c28@huawei.com> (raw)
In-Reply-To: <c9eb7f53-db46-4229-b9ef-8faa1138aca7@huawei.com>
Sorry to self-reply
On 3/18/2026 10:02 AM, fengchengwen wrote:
> Hi,
>
> On 3/18/2026 5:38 AM, Jeremy Linton wrote:
>> Hi,
>>
>> Lets try this again, since the last one looks like it got caught in the moderation system and wasn't quite right anyway.
>>
>> On 3/12/26 9:21 PM, Chengwen Feng wrote:
>>> Unify CPU ACPI ID retrieval interface across architectures by
>>> refactoring get_acpi_id_for_cpu() to acpi_get_cpu_uid() on
>>> arm64/riscv/loongarch:
>>> - Add input parameter validation
>>> - Adjust interface to int acpi_get_cpu_uid(unsigned int cpu, u32 *uid)
>>> (old: u32 get_acpi_id_for_cpu(unsigned int cpu), no input check)
>>>
>>> This refactoring (not a pure rename) enhances interface robustness while
>>> preparing for consistent ACPI Processor UID retrieval across all
>>> ACPI-enabled platforms. Valid inputs retain original behavior.
>>>
>>> Note: Move the ARM64-specific get_cpu_for_acpi_id() implementation to
>>> arch/arm64/kernel/acpi_numa.c to fix compilation errors from
>>> circular header dependencies introduced by the rename.
>>>
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
>>> ---
>>> arch/arm64/include/asm/acpi.h | 16 +---------
>>> arch/arm64/kernel/acpi.c | 16 ++++++++++
>>> arch/arm64/kernel/acpi_numa.c | 14 +++++++++
>>> arch/loongarch/include/asm/acpi.h | 5 ---
>>> arch/loongarch/kernel/acpi.c | 9 ++++++
>>> arch/riscv/include/asm/acpi.h | 4 ---
>>> arch/riscv/kernel/acpi.c | 16 ++++++++++
>>> arch/riscv/kernel/acpi_numa.c | 9 ++++--
>>> drivers/acpi/pptt.c | 50 ++++++++++++++++++++++--------
>>> drivers/acpi/riscv/rhct.c | 7 ++++-
>>> drivers/perf/arm_cspmu/arm_cspmu.c | 6 ++--
>>> include/linux/acpi.h | 13 ++++++++
>>> 12 files changed, 122 insertions(+), 43 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>>> index c07a58b96329..106a08556cbf 100644
>>> --- a/arch/arm64/include/asm/acpi.h
>>> +++ b/arch/arm64/include/asm/acpi.h
>>> @@ -114,22 +114,8 @@ static inline bool acpi_has_cpu_in_madt(void)
>>> }
>>> struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu);
>>> -static inline u32 get_acpi_id_for_cpu(unsigned int cpu)
>>> -{
>>> - return acpi_cpu_get_madt_gicc(cpu)->uid;
>>> -}
>>> -
>>> -static inline int get_cpu_for_acpi_id(u32 uid)
>>> -{
>>> - int cpu;
>>> -
>>> - for (cpu = 0; cpu < nr_cpu_ids; cpu++)
>>> - if (acpi_cpu_get_madt_gicc(cpu) &&
>>> - uid == get_acpi_id_for_cpu(cpu))
>>> - return cpu;
>>> - return -EINVAL;
>>> -}
>>> +int get_cpu_for_acpi_id(u32 uid);
>>> static inline void arch_fix_phys_package_id(int num, u32 slot) { }
>>> void __init acpi_init_cpus(void);
>>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>>> index af90128cfed5..f3866606fc46 100644
>>> --- a/arch/arm64/kernel/acpi.c
>>> +++ b/arch/arm64/kernel/acpi.c
>>> @@ -458,3 +458,19 @@ int acpi_unmap_cpu(int cpu)
>>> }
>>> EXPORT_SYMBOL(acpi_unmap_cpu);
>>> #endif /* CONFIG_ACPI_HOTPLUG_CPU */
>>> +
>>> +int acpi_get_cpu_uid(unsigned int cpu, u32 *uid)
>>> +{
>>> + struct acpi_madt_generic_interrupt *gicc;
>>> +
>>> + if (cpu >= nr_cpu_ids)
>>> + return -EINVAL;
>> If this actually happens, its probably useful to know it with a pr_warn/pr_warn_once.> +
>
> The function maybe called from userspace which on later roadmap, so I prefer not add
> warning or error here.
> BTW: the function will return -EINVAL, so caller could know the case.
>
>>> + gicc = acpi_cpu_get_madt_gicc(cpu);
>>> + if (!gicc)
>> I think this check is redundant because we can't have logical cpu's that aren't in the cpu_possible() list, which on arm64 doesn't AFAIK have holes. In the past this might have made sense if we weren't maintaining a copy of the gicc structure from the MADT for each core.> + return -ENODEV;
>
> This commit will backport to stable branch at least 6.6. So I think it's OK to keep it.
>
>>> +
>>> + *uid = gicc->uid;
>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(acpi_get_cpu_uid);
>>> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
>>> index 2465f291c7e1..41d1e46a4338 100644
>>> --- a/arch/arm64/kernel/acpi_numa.c
>>> +++ b/arch/arm64/kernel/acpi_numa.c
>>> @@ -34,6 +34,20 @@ int __init acpi_numa_get_nid(unsigned int cpu)
>>> return acpi_early_node_map[cpu];
>>> }
>>> +int get_cpu_for_acpi_id(u32 uid)
>>> +{
>>> + u32 cpu_uid;
>>> + int ret;
>>> +
>>> + for (int cpu = 0; cpu < nr_cpu_ids; cpu++) {
>>> + ret = acpi_get_cpu_uid(cpu, &cpu_uid);
>> This might have been a simplification, but since we are basically doing a for_each_possible_cpu(cpu) and every possible cpu will have a GICC entry before it becomes 'possible' there will be a UID, so all the error checking AFAIK, is impossible here.> + if (ret == 0 && uid == cpu_uid)
>
> I prefer to keep the current impl, as it may catch future error.
>
>>> + return cpu;
>>> + }
>>> +
>>> + return -EINVAL;
>>> +}
>>> +
>> I also moved this below acpi_get_cpu_uid() in acpi.c and I don't see the a forward error issue you mentioned. It seems to me that they should be kept close to each other since they are basically inverses of each other.
>
> As long as you ensure that it is not placed in asm/acpi.h, that's fine.
> So it's OK to move this function to acpi.c
>
> But I just checked the callers of this function again and found that there are
> all in acpi_numa.c, so I will now add the static keyword to this function and
> make it an internal function.
I just found drivers/irqchip/irq-gic-v3.c has a call for get_cpu_for_acpi_id,
so We should not marking as static.
According to your advise, I moved it in acpi.c in v8.
Thanks
>
> Thanks
>
>>
>
next prev parent reply other threads:[~2026-03-18 4:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 2:21 [PATCH v7 0/3] Fix get cpu steer-tag fail on ARM64 platform Chengwen Feng
2026-03-13 2:21 ` [PATCH v7 1/3] ACPI: Refactor get_acpi_id_for_cpu() to acpi_get_cpu_uid() on non-x86 Chengwen Feng
2026-03-17 21:21 ` Jeremy Linton
2026-03-17 21:38 ` Jeremy Linton
2026-03-18 2:02 ` fengchengwen
2026-03-18 4:04 ` fengchengwen [this message]
2026-03-13 2:21 ` [PATCH v7 2/3] x86: Implement acpi_get_cpu_uid() Chengwen Feng
2026-03-13 2:21 ` [PATCH v7 3/3] PCI/TPH: Fix get cpu steer-tag fail on ARM64 platform Chengwen Feng
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=0744ee77-78ee-4e3d-9f0d-e8fe44be1c28@huawei.com \
--to=fengchengwen@huawei.com \
--cc=Eric.VanTassell@amd.com \
--cc=anshuman.khandual@arm.com \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=chenl311@chinatelecom.cn \
--cc=guohanjun@huawei.com \
--cc=heinrich.schuchardt@canonical.com \
--cc=jeremy.linton@arm.com \
--cc=jonathan.cameron@huawei.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=liuyonglong@huawei.com \
--cc=loongarch@lists.linux.dev \
--cc=masahiroy@kernel.org \
--cc=punit.agrawal@oss.qualcomm.com \
--cc=rafael@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=stable@vger.kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=wanghuiqiang@huawei.com \
--cc=wangyuquan1236@phytium.com.cn \
--cc=wangzhou1@hisilicon.com \
--cc=will@kernel.org \
--cc=xen-devel@lists.xenproject.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