From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1A842391831; Tue, 17 Mar 2026 21:38:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773783495; cv=none; b=ARlNr58CGDddW6EqCnXx/fk2JLizJkN+s/viLMSTBLjPTbIgy0R6EQFWdb3C820rSgFrv+9d2e5IqpMxuKI8s7mqpQu8p4PF8f0L1GgYQTReEYzyIQabpGgLDQS+fffozxYTEMml/CzUT5NuRX4c7bLIsMPACw9fCsqrRrJtCfo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773783495; c=relaxed/simple; bh=IROtxSZbQxzVA3jvI9dW9jeRBXHSY1MInI2EvT1PUH0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=blSRblOIaQ+Vm6ZJ6Q2CB1Nsm2fInExfubT+mMzcM8ZEtT3mg15WXVWfziLJoFH9eiWh8SonNe4IpWfbatCweXRsY6DDDKao4Ro3p60Fyv4adnSoIIdWanX8dm+/rH8ABygeuJiUyKR2pO+yHTztzKcTokd2FksEZKu3gOa/m9A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 419131477; Tue, 17 Mar 2026 14:38:07 -0700 (PDT) Received: from [172.27.42.179] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E05563F73B; Tue, 17 Mar 2026 14:38:11 -0700 (PDT) Message-ID: Date: Tue, 17 Mar 2026 16:38:11 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 1/3] ACPI: Refactor get_acpi_id_for_cpu() to acpi_get_cpu_uid() on non-x86 To: Chengwen Feng , Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" 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 References: <20260313022144.40942-1-fengchengwen@huawei.com> <20260313022144.40942-2-fengchengwen@huawei.com> Content-Language: en-US From: Jeremy Linton In-Reply-To: <20260313022144.40942-2-fengchengwen@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > Reviewed-by: Jonathan Cameron > --- > 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.> + > + 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; > + > + *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) > + 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.