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 8BCF925744D; Thu, 28 Aug 2025 15:58:03 +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=1756396685; cv=none; b=IswHYKFbN+nyNBp4rpMpzcFcrktfZYJ3mQPfONofqk29+bsoyCZxt8bf+paZjp1Q3t79m73nUfhbePQ27BReiLa4ODdhUQtGQCprMUsHYxoczLXiZ0Ov1mf7yoZSGOKrwm7FxX7ycpqrxnivijefbp0bD6q4OwCWt4uNKDuQ8cg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756396685; c=relaxed/simple; bh=V1qiqwurLe1DRj4mhXRsbO/UrN4a9Fy7Q6AABkiLF7s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WUc5wJozo2A9c2t9GshZ2pPGETVfBJPqRAvl19qbI6jpRcHQCFmFGBFTslsTQj7Vo9XzTz1Qg9qO5g/WeResmFGWSN19yujRZc/L0SW/z8jr30KOgdO6oE3HFViVaVppMaGWNZlZIq98DdJ6RZRjSDEytvjFXXZI0BUFIaIVZPA= 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 8E7AA1A32; Thu, 28 Aug 2025 08:57:54 -0700 (PDT) Received: from [10.1.196.42] (eglon.cambridge.arm.com [10.1.196.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 23C883F694; Thu, 28 Aug 2025 08:57:55 -0700 (PDT) Message-ID: Date: Thu, 28 Aug 2025 16:57:55 +0100 Precedence: bulk X-Mailing-List: linux-acpi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 05/33] ACPI / PPTT: Find cache level by cache-id To: Ben Horgan , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org, devicetree@vger.kernel.org Cc: D Scott Phillips OS , carl@os.amperecomputing.com, lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com, baolin.wang@linux.alibaba.com, Jamie Iles , Xin Hao , peternewman@google.com, dfustini@baylibre.com, amitsinght@marvell.com, David Hildenbrand , Rex Nie , Dave Martin , Koba Ko , Shanker Donthineni , fenghuay@nvidia.com, baisheng.gao@unisoc.com, Jonathan Cameron , Rob Herring , Rohit Mathew , Rafael Wysocki , Len Brown , Lorenzo Pieralisi , Hanjun Guo , Sudeep Holla , Krzysztof Kozlowski , Conor Dooley , Catalin Marinas , Will Deacon , Greg Kroah-Hartman , Danilo Krummrich References: <20250822153048.2287-1-james.morse@arm.com> <20250822153048.2287-6-james.morse@arm.com> <9ce36190-6d99-4a41-a803-a65be677db2d@arm.com> Content-Language: en-GB From: James Morse In-Reply-To: <9ce36190-6d99-4a41-a803-a65be677db2d@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Ben, On 27/08/2025 10:25, Ben Horgan wrote: > On 8/22/25 16:29, James Morse wrote: >> The MPAM table identifies caches by id. The MPAM driver also wants to know >> the cache level to determine if the platform is of the shape that can be >> managed via resctrl. Cacheinfo has this information, but only for CPUs that >> are online. >> >> Waiting for all CPUs to come online is a problem for platforms where >> CPUs are brought online late by user-space. >> >> Add a helper that walks every possible cache, until it finds the one >> identified by cache-id, then return the level. >> Add a cleanup based free-ing mechanism for acpi_get_table(). >> diff --git a/include/linux/acpi.h b/include/linux/acpi.h >> index f97a9ff678cc..30c10b1dcdb2 100644 >> --- a/include/linux/acpi.h >> +++ b/include/linux/acpi.h >> @@ -221,6 +222,17 @@ void acpi_reserve_initial_tables (void); >> void acpi_table_init_complete (void); >> int acpi_table_init (void); >> >> +static inline struct acpi_table_header *acpi_get_table_ret(char *signature, u32 instance) >> +{ >> + struct acpi_table_header *table; >> + int status = acpi_get_table(signature, instance, &table); >> + >> + if (ACPI_FAILURE(status)) >> + return ERR_PTR(-ENOENT); >> + return table; >> +} >> +DEFINE_FREE(acpi_table, struct acpi_table_header *, if (!IS_ERR(_T)) acpi_put_table(_T)) > nit: Is it useful to change the condition from !IS_ERR(_T) to > !IS_ERR_OR_NULL(_T)? This seems to be the common pattern. I do note that > acpi_put_table() can take NULL, so there is no real danger. If it's the common pattern, sure. But this code got dropped as Dave pointed out the PPTT doesn't care about the reference counting anyway, its acpi_get_pptt() helper just uses the same reference for everything. This might come back for the MPAM driver.. >> + >> int acpi_table_parse(char *id, acpi_tbl_table_handler handler); >> int __init_or_acpilib acpi_table_parse_entries(char *id, >> unsigned long table_size, int entry_id, Thanks, James