From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (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 D88BC1E50A; Tue, 30 Apr 2024 11:07:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714475242; cv=none; b=JUWz8hmjhlUQBYGWWj+bWn15Q42ztMLCG9fR6Jle3FDAWiZxpC6PcJpdPgYQpZqNPyd0qMqRMHLb32bY+gNFeHYCd5Gmg86zSuNB3BfhdTdHthj9wTF2j5/Hfx0TBSgaf/DTeUDQIlKcjYdh7OPSHklpYPIKyVLnxz+/zgePwlM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714475242; c=relaxed/simple; bh=3qxr+TObkd/zG873vQZ3MoGhZ/M55hk6OTuRvE2QsSQ=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=AFqv/67FPfaNyLOMxtwX9zQM/pNn412yk/TKwHAG15kh7SnhUR4X//5SGkrmGKrhFL/MPvBwfj2PozNC2BAaguatnFYWbtYkNT37Mx4z5UDRQCJXb0E6qtOneqWAJNWLQ5DpAhfGBCtupiEiuYp/bgMg2WQOjGK34ESNLGxNUTs= 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; arc=none smtp.client-ip=185.176.79.56 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 Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VTHQW5wKlz6J6mX; Tue, 30 Apr 2024 19:04:35 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id 34773140B2A; Tue, 30 Apr 2024 19:07:16 +0800 (CST) Received: from localhost (10.122.247.231) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Tue, 30 Apr 2024 12:07:15 +0100 Date: Tue, 30 Apr 2024 12:07:14 +0100 From: Jonathan Cameron To: Gavin Shan CC: Thomas Gleixner , Peter Zijlstra , , , , , , , , , Russell King , "Rafael J . Wysocki" , Miguel Luis , James Morse , Salil Mehta , "Jean-Philippe Brucker" , Catalin Marinas , Will Deacon , Marc Zyngier , Hanjun Guo , Ingo Molnar , Borislav Petkov , Dave Hansen , , , , Lorenzo Pieralisi , "Sudeep Holla" Subject: Re: [PATCH v8 05/16] ACPI: processor: Add acpi_get_processor_handle() helper Message-ID: <20240430120714.00007ee3@huawei.com> In-Reply-To: <63f7c71a-fa01-4604-8fc6-9f52b5b31d6b@redhat.com> References: <20240426135126.12802-1-Jonathan.Cameron@huawei.com> <20240426135126.12802-6-Jonathan.Cameron@huawei.com> <63f7c71a-fa01-4604-8fc6-9f52b5b31d6b@redhat.com> Organization: Huawei Technologies R&D (UK) Ltd. X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.29; x86_64-w64-mingw32) Precedence: bulk X-Mailing-List: linux-arch@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: lhrpeml100006.china.huawei.com (7.191.160.224) To lhrpeml500005.china.huawei.com (7.191.163.240) On Tue, 30 Apr 2024 14:26:06 +1000 Gavin Shan wrote: > On 4/26/24 23:51, Jonathan Cameron wrote: > > If CONFIG_ACPI_PROCESSOR provide a helper to retrieve the > > acpi_handle for a given CPU allowing access to methods > > in DSDT. > > > > Tested-by: Miguel Luis > > Signed-off-by: Jonathan Cameron > > > > --- > > v8: Code simplification suggested by Rafael. > > Fixup ;; spotted by Gavin > > --- > > drivers/acpi/acpi_processor.c | 11 +++++++++++ > > include/linux/acpi.h | 7 +++++++ > > 2 files changed, 18 insertions(+) > > > > Reviewed-by: Gavin Shan > Thanks, > > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c > > index 3b180e21f325..ecc2721fecae 100644 > > --- a/drivers/acpi/acpi_processor.c > > +++ b/drivers/acpi/acpi_processor.c > > @@ -35,6 +35,17 @@ EXPORT_PER_CPU_SYMBOL(processors); > > struct acpi_processor_errata errata __read_mostly; > > EXPORT_SYMBOL_GPL(errata); > > > > +acpi_handle acpi_get_processor_handle(int cpu) > > +{ > > + struct acpi_processor *pr; > > + > > + pr = per_cpu(processors, cpu); > > + if (pr) > > + return pr->handle; > > + > > + return NULL; > > +} > > + > > Maybe it's worthy to have more check here, something like below. > However, it's also fine without the extra check. We could harden this, but for now the call sites are only int arch_(un)register_cpu() so if we get there with either of these failing something went very wrong. Maybe if it gets used more widely this defense would be wise. Jonathan > > if (cpu >= nr_cpu_ids || !cpu_possible(cpu)) > return NULL; > > > static int acpi_processor_errata_piix4(struct pci_dev *dev) > > { > > u8 value1 = 0; > > diff --git a/include/linux/acpi.h b/include/linux/acpi.h > > index 34829f2c517a..9844a3f9c4e5 100644 > > --- a/include/linux/acpi.h > > +++ b/include/linux/acpi.h > > @@ -309,6 +309,8 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, u32 acpi_id, > > int acpi_unmap_cpu(int cpu); > > #endif /* CONFIG_ACPI_HOTPLUG_CPU */ > > > > +acpi_handle acpi_get_processor_handle(int cpu); > > + > > #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC > > int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr); > > #endif > > @@ -1077,6 +1079,11 @@ static inline bool acpi_sleep_state_supported(u8 sleep_state) > > return false; > > } > > > > +static inline acpi_handle acpi_get_processor_handle(int cpu) > > +{ > > + return NULL; > > +} > > + > > #endif /* !CONFIG_ACPI */ > > > > extern void arch_post_acpi_subsys_init(void); > > Thanks, > Gavin >