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 058B11922FD; Fri, 24 Oct 2025 14:15:24 +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=1761315328; cv=none; b=dQGJItQT74sPXh8Hry7hYDynonB3sisIpTwYVVZ/Cc2fA00NeaZLkYMRZ9LOiHaDJ7oxSC18VL+Byd1WnAOqEO7DW7/LEKjC6vJP9BtiTcrDNX9jQrJHaaXYEkgN4tfEjBXxWCvx5+aRhCl42hcDsQMAYfLMWERVktQqxDU9Jms= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761315328; c=relaxed/simple; bh=hLcPIyyWr6TcBq/BNFlyubdecmp8T71I9Txq97gZs4o=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dk9DaYBRuu6J44kELX3XYyfHxWguHQVjlUyGo16cJeTmwosk/mSLegVrjAEZqyUhGIWNlo4TnTEa0i6NzqYEzbs3aEQ75yVweUfCjIYgtDXPTGbvIDnGg10Q0hZ8MEa0I4DFKePoZqlL/lnCKZYVFTHXK6IGHkawEy2ic2gGFIs= 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.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4ctPyl29wQz6L4vm; Fri, 24 Oct 2025 22:13:51 +0800 (CST) Received: from dubpeml100005.china.huawei.com (unknown [7.214.146.113]) by mail.maildlp.com (Postfix) with ESMTPS id 48410140279; Fri, 24 Oct 2025 22:15:22 +0800 (CST) Received: from localhost (10.203.177.15) by dubpeml100005.china.huawei.com (7.214.146.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 24 Oct 2025 15:15:20 +0100 Date: Fri, 24 Oct 2025 15:15:19 +0100 From: Jonathan Cameron To: James Morse CC: , , , D Scott Phillips OS , , , , , , Jamie Iles , Xin Hao , , , , David Hildenbrand , Dave Martin , Koba Ko , Shanker Donthineni , , , Rob Herring , Rohit Mathew , "Rafael Wysocki" , Len Brown , Lorenzo Pieralisi , Hanjun Guo , Sudeep Holla , Catalin Marinas , "Will Deacon" , Greg Kroah-Hartman , Danilo Krummrich , Jeremy Linton , Gavin Shan Subject: Re: [PATCH v3 03/29] ACPI / PPTT: Find cache level by cache-id Message-ID: <20251024151519.000058a8@huawei.com> In-Reply-To: <20251017185645.26604-4-james.morse@arm.com> References: <20251017185645.26604-1-james.morse@arm.com> <20251017185645.26604-4-james.morse@arm.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) Precedence: bulk X-Mailing-List: linux-acpi@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: lhrpeml500009.china.huawei.com (7.191.174.84) To dubpeml100005.china.huawei.com (7.214.146.113) On Fri, 17 Oct 2025 18:56:19 +0000 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. > > Signed-off-by: James Morse > Reviewed-by: Fenghua Yu > Reviewed-by: Gavin Shan > Tested-by: Fenghua Yu > --- > Changes sinec v2: > * Search all caches, not just unified caches. This removes the need to count > the caches first, but means a failure to find the table walks the table > three times for different cache types. Fwiw that sentence doesn't make sense to me. Too many tables. > * Fixed return value of the no-acpi stub. > * Punctuation typo in a comment, > * Keep trying to parse the table even if a bogus CPU is encountered. > * Specified CPUs share caches with other CPUs. Trivial comment only from me. Ben's question on matching an ID against an l1 instruction cache needs addressing (or ruling out as a 'won't fix') though before an RB is appropriate. > /** > * update_cache_properties() - Update cacheinfo for the given processor > * @this_leaf: Kernel cache info structure being updated > @@ -903,3 +924,64 @@ void acpi_pptt_get_cpus_from_container(u32 acpi_cpu_id, cpumask_t *cpus) > entry->length); > } > } > + > +/* Smells like kernel doc. Why not /** ? Then can at least verify formatting etc. > + * find_acpi_cache_level_from_id() - Get the level of the specified cache > + * @cache_id: The id field of the cache > + * > + * Determine the level relative to any CPU for the cache identified by > + * cache_id. This allows the property to be found even if the CPUs are offline. > + * > + * The returned level can be used to group caches that are peers. > + * > + * The PPTT table must be rev 3 or later. > + * > + * If one CPU's L2 is shared with another CPU as L3, this function will return > + * an unpredictable value. > + * > + * Return: -ENOENT if the PPTT doesn't exist, the revision isn't supported or > + * the cache cannot be found. > + * Otherwise returns a value which represents the level of the specified cache. > + */