From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0FE2D262FDC; Wed, 18 Mar 2026 04:04:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.187 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773806665; cv=none; b=siEnGK+Ha+gD3mHAz5sOKl/zRNO806ojBW4JtkkaW9T1v89zWdy1UpbxPOVexCiNQByeloWlxdvanI9snrJWO1rMKrtV4M3orQ5Wq+4GsIAPw893B6AAd8PAeW9Z60P2wXjsHJSdq/e+Yp9b5HHd8O1IOzlisqxbmvNKUulAmXY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773806665; c=relaxed/simple; bh=Dt5Oam7a8ddqq3BfktyQN9kIOpoRHtuXRpWswvc3GAs=; h=Message-ID:Date:MIME-Version:Subject:From:To:CC:References: In-Reply-To:Content-Type; b=X2k0uAeGVyuUi0l1u69p2NJifwuEjybK8ALixmANy91hyaOW3q1lJVpXaKV+Z2WFP08f6dNwfwhhSiL/c7UNa7g9wm1j7KyWzUQXscYcrRBzkafktmg8Ehwd0wOlJR5oQpIKq+zQQdhUzvGQq05HN09slF9goks6XN5bV/JGHV4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=tgKSLKH3; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=tgKSLKH3; arc=none smtp.client-ip=45.249.212.187 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="tgKSLKH3"; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="tgKSLKH3" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=XZKg5HSzqw961TE78Y1nHw4DDOpQ3KVITP3+xW3FZMU=; b=tgKSLKH3FRXeuZflU+YmXS6o6Nivgvm0hUbiV+64ojQwdlRuj748sRRNImMTKVJ0zSqQ4mFD9 vyWfROqFApjH8PJl/yObRR3ZUwmsw9hG0AiTaunIlNM5kOdnbqS/nXO8pxQZ0gDOyc2ERqq/FSD tUkS7f1ubwBj8AMZrIXLpUM= Received: from canpmsgout03.his.huawei.com (unknown [172.19.92.159]) by szxga01-in.huawei.com (SkyGuard) with ESMTPS id 4fbFYS5SRyz1BFwf; Wed, 18 Mar 2026 12:03:24 +0800 (CST) dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=XZKg5HSzqw961TE78Y1nHw4DDOpQ3KVITP3+xW3FZMU=; b=tgKSLKH3FRXeuZflU+YmXS6o6Nivgvm0hUbiV+64ojQwdlRuj748sRRNImMTKVJ0zSqQ4mFD9 vyWfROqFApjH8PJl/yObRR3ZUwmsw9hG0AiTaunIlNM5kOdnbqS/nXO8pxQZ0gDOyc2ERqq/FSD tUkS7f1ubwBj8AMZrIXLpUM= Received: from mail.maildlp.com (unknown [172.19.162.197]) by canpmsgout03.his.huawei.com (SkyGuard) with ESMTPS id 4fbFSC5sDgzpTMG; Wed, 18 Mar 2026 11:58:51 +0800 (CST) Received: from kwepemk500009.china.huawei.com (unknown [7.202.194.94]) by mail.maildlp.com (Postfix) with ESMTPS id 19BFD40569; Wed, 18 Mar 2026 12:04:15 +0800 (CST) Received: from [10.67.121.161] (10.67.121.161) by kwepemk500009.china.huawei.com (7.202.194.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 18 Mar 2026 12:04:14 +0800 Message-ID: <0744ee77-78ee-4e3d-9f0d-e8fe44be1c28@huawei.com> Date: Wed, 18 Mar 2026 12:04:13 +0800 Precedence: bulk X-Mailing-List: linux-doc@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 From: fengchengwen To: Jeremy Linton , Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" CC: , , , , , , , , , , , , , , , , , , , , , , , References: <20260313022144.40942-1-fengchengwen@huawei.com> <20260313022144.40942-2-fengchengwen@huawei.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemk500009.china.huawei.com (7.202.194.94) 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 >>> 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.> + > > 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 > >> >