linux-kernel - [PATCH 02/33] ACPI / PPTT: Stop acpi_count_levels() expecting callers to clear levels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251107123450.664001-3-ben.horgan@arm.com>
Date: Fri,  7 Nov 2025 12:34:19 +0000
From: Ben Horgan <ben.horgan@....com>
To: james.morse@....com
Cc: amitsinght@...vell.com,
	baisheng.gao@...soc.com,
	baolin.wang@...ux.alibaba.com,
	bobo.shaobowang@...wei.com,
	carl@...amperecomputing.com,
	catalin.marinas@....com,
	dakr@...nel.org,
	dave.martin@....com,
	david@...hat.com,
	dfustini@...libre.com,
	fenghuay@...dia.com,
	gregkh@...uxfoundation.org,
	gshan@...hat.com,
	guohanjun@...wei.com,
	jeremy.linton@....com,
	jonathan.cameron@...wei.com,
	kobak@...dia.com,
	lcherian@...vell.com,
	lenb@...nel.org,
	linux-acpi@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	lpieralisi@...nel.org,
	peternewman@...gle.com,
	quic_jiles@...cinc.com,
	rafael@...nel.org,
	robh@...nel.org,
	rohit.mathew@....com,
	scott@...amperecomputing.com,
	sdonthineni@...dia.com,
	sudeep.holla@....com,
	tan.shaopeng@...itsu.com,
	will@...nel.org,
	xhao@...ux.alibaba.com,
	Shaopeng Tan <tan.shaopeng@...fujitsu.com>,
	Ben Horgan <ben.horgan@....com>
Subject: [PATCH 02/33] ACPI / PPTT: Stop acpi_count_levels() expecting callers to clear levels

From: James Morse <james.morse@....com>

In acpi_count_levels(), the initial value of *levels passed by the
caller is really an implementation detail of acpi_count_levels(), so it
is unreasonable to expect the callers of this function to know what to
pass in for this parameter.  The only sensible initial value is 0,
which is what the only upstream caller (acpi_get_cache_info()) passes.

Use a local variable for the starting cache level in acpi_count_levels(),
and pass the result back to the caller via the function return value.

Get rid of the levels parameter, which has no remaining purpose.

Fix acpi_get_cache_info() to match.

Suggested-by: Jonathan Cameron <jonathan.cameron@...wei.com>
Signed-off-by: James Morse <james.morse@....com>
Reviewed-by: Lorenzo Pieralisi <lpieralisi@...nel.org>
Reviewed-by: Jonathan Cameron <jonathan.cameron@...wei.com>
Reviewed-by: Fenghua Yu <fenghuay@...dia.com>
Tested-by: Fenghua Yu <fenghuay@...dia.com>
Tested-by: Shaopeng Tan <tan.shaopeng@...fujitsu.com>
Tested-by: Peter Newman <peternewman@...gle.com>
Reviewed-by: Gavin Shan <gshan@...hat.com>
Signed-off-by: Ben Horgan <ben.horgan@....com>
---
Changes since v3:
s/starting_level/current_level/ (Jonathan)
---
 drivers/acpi/pptt.c | 20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
index 69917cc6bd2f..1027ca3566b1 100644
--- a/drivers/acpi/pptt.c
+++ b/drivers/acpi/pptt.c
@@ -177,14 +177,14 @@ acpi_find_cache_level(struct acpi_table_header *table_hdr,
 }
 
 /**
- * acpi_count_levels() - Given a PPTT table, and a CPU node, count the cache
- * levels and split cache levels (data/instruction).
+ * acpi_count_levels() - Given a PPTT table, and a CPU node, count the
+ * total number of levels and split cache levels (data/instruction).
  * @table_hdr: Pointer to the head of the PPTT table
  * @cpu_node: processor node we wish to count caches for
- * @levels: Number of levels if success.
  * @split_levels:	Number of split cache levels (data/instruction) if
  *			success. Can by NULL.
  *
+ * Return: number of levels.
  * Given a processor node containing a processing unit, walk into it and count
  * how many levels exist solely for it, and then walk up each level until we hit
  * the root node (ignore the package level because it may be possible to have
@@ -192,14 +192,18 @@ acpi_find_cache_level(struct acpi_table_header *table_hdr,
  * split cache levels (data/instruction) that exist at each level on the way
  * up.
  */
-static void acpi_count_levels(struct acpi_table_header *table_hdr,
-			      struct acpi_pptt_processor *cpu_node,
-			      unsigned int *levels, unsigned int *split_levels)
+static int acpi_count_levels(struct acpi_table_header *table_hdr,
+			     struct acpi_pptt_processor *cpu_node,
+			     unsigned int *split_levels)
 {
+	int current_level = 0;
+
 	do {
-		acpi_find_cache_level(table_hdr, cpu_node, levels, split_levels, 0, 0);
+		acpi_find_cache_level(table_hdr, cpu_node, &current_level, split_levels, 0, 0);
 		cpu_node = fetch_pptt_node(table_hdr, cpu_node->parent);
 	} while (cpu_node);
+
+	return current_level;
 }
 
 /**
@@ -645,7 +649,7 @@ int acpi_get_cache_info(unsigned int cpu, unsigned int *levels,
 	if (!cpu_node)
 		return -ENOENT;
 
-	acpi_count_levels(table, cpu_node, levels, split_levels);
+	*levels = acpi_count_levels(table, cpu_node, split_levels);
 
 	pr_debug("Cache Setup: last_level=%d split_levels=%d\n",
 		 *levels, split_levels ? *split_levels : -1);
-- 
2.43.0