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 4D515248F7C; Mon, 10 Nov 2025 16:04:46 +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=1762790688; cv=none; b=UMbZGo9PvsZHVMgXtuz+TIKYylu/EUXZrphd8Dd+ILTIg41EoIlKEpAYeIVsPGofF0N4+GxvezXosjxM2nQuEJF++2P+via2rCcRHqH2UYP4el8dqhcp0649JvMkgbGs2oDPJk8KLD5UI7OLEH0GeMHW7CWPq5QRbfg5ViyCMQU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762790688; c=relaxed/simple; bh=T4xLMbTwLHpmS8LeynKWwHGMyvbAvTUMl6BSQhPotPw=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=kMY2PJBKMXqFF1ACdfFQPD/jwypncrCk/K/ia7cZdPQpfG8zJP4n0Sdn0HYvYUEKFXV9lnSRKX1auKrfRjxOsfmUd2lJ2HG1TEIa65yzIaaWC/gF7AT6VyMdVA3ObwsUT6GpGNCdNRY+MK9WgUoBWIRhnDkOOwwRUfp8Qbg8gRQ= 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 ESMTPS id 4d4vcG0Y1hzJ46C2; Tue, 11 Nov 2025 00:04:14 +0800 (CST) Received: from dubpeml100005.china.huawei.com (unknown [7.214.146.113]) by mail.maildlp.com (Postfix) with ESMTPS id 8353D140446; Tue, 11 Nov 2025 00:04:43 +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.36; Mon, 10 Nov 2025 16:04:41 +0000 Date: Mon, 10 Nov 2025 16:04:40 +0000 From: Jonathan Cameron To: Ben Horgan CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH 05/33] ACPI / PPTT: Add a helper to fill a cpumask from a cache_id Message-ID: <20251110160440.000054c6@huawei.com> In-Reply-To: <20251107123450.664001-6-ben.horgan@arm.com> References: <20251107123450.664001-1-ben.horgan@arm.com> <20251107123450.664001-6-ben.horgan@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: lhrpeml100010.china.huawei.com (7.191.174.197) To dubpeml100005.china.huawei.com (7.214.146.113) On Fri, 7 Nov 2025 12:34:22 +0000 Ben Horgan wrote: > From: James Morse > > MPAM identifies CPUs by the cache_id in the PPTT cache structure. > > The driver needs to know which CPUs are associated with the cache. > The CPUs may not all be online, so cacheinfo does not have the > information. > > Add a helper to pull this information out of the PPTT. > > CC: Rohit Mathew > Signed-off-by: James Morse > Signed-off-by: Ben Horgan Very similar comments to on previous. > --- > Changes since v3: > Equivalent changes to the previous patch: > Tags dropped due to rework > Fallout/simplification from adding acpi_pptt_cache_v1_full > Look for each cache type before incrementing level > --- > drivers/acpi/pptt.c | 62 ++++++++++++++++++++++++++++++++++++++++++++ > include/linux/acpi.h | 6 +++++ > 2 files changed, 68 insertions(+) > > diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c > index 71841c106020..7b4cb17c12c0 100644 > --- a/drivers/acpi/pptt.c > +++ b/drivers/acpi/pptt.c > @@ -981,3 +981,65 @@ int find_acpi_cache_level_from_id(u32 cache_id) > > return -ENOENT; > } > + > +/** > + * acpi_pptt_get_cpumask_from_cache_id() - Get the cpus associated with the > + * specified cache > + * @cache_id: The id field of the cache > + * @cpus: Where to build the cpumask > + * > + * Determine which CPUs are below this cache in the PPTT. This allows the property > + * to be found even if the CPUs are offline. > + * > + * The PPTT table must be rev 3 or later, > + * > + * Return: -ENOENT if the PPTT doesn't exist, or the cache cannot be found. > + * Otherwise returns 0 and sets the cpus in the provided cpumask. > + */ > +int acpi_pptt_get_cpumask_from_cache_id(u32 cache_id, cpumask_t *cpus) > +{ > + int cpu; > + struct acpi_table_header *table; > + > + cpumask_clear(cpus); > + > + table = acpi_get_pptt(); > + if (!table) > + return -ENOENT; > + > + if (table->revision < 3) > + return -ENOENT; > + > + for_each_possible_cpu(cpu) { > + bool not_empty = true; Basically same comments. This dance of setting it not_empty to get into the loop is a bit nasty as it means that variable is briefly has an alternative meaning the name doesn't convey. A do/while() doesn't have that problem as we always do one iteration. > + u32 acpi_cpu_id; > + struct acpi_pptt_cache_v1_full *cache; > + struct acpi_pptt_processor *cpu_node; > + > + acpi_cpu_id = get_acpi_id_for_cpu(cpu); > + cpu_node = acpi_find_processor_node(table, acpi_cpu_id); > + if (!cpu_node) > + continue; > + > + for (int level = 1; not_empty; level++) { > + int cache_type[] = {CACHE_TYPE_INST, CACHE_TYPE_DATA, CACHE_TYPE_UNIFIED}; > + > + not_empty = false; > + for (int i = 0; i < ARRAY_SIZE(cache_type); i++) { > + cache = acpi_find_cache_node(table, acpi_cpu_id, cache_type[i], > + level, &cpu_node); > + > + if (!cache) > + continue; > + > + not_empty = true; > + > + if (acpi_pptt_cache_id_is_valid(cache) && > + cache->extra.cache_id == cache_id) > + cpumask_set_cpu(cpu, cpus); > + } > + } > + } > + > + return 0; > +}