From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zeus03.de (zeus03.de [194.117.254.33]) (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 5F68A3F8249 for ; Mon, 29 Jun 2026 08:57:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=194.117.254.33 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782723442; cv=none; b=cyWSPuAz174/AeLsvH/CioOf1FiN7CNmgpnn+VPi4l3+cti5tXsp0xDpS7Bw4M0F2BFy4Zd8R4aQ9WMZxwTmwbCGKkEFud/lwXeo8mQqaJcnp5sKoq5RJ5jTCf+b0/N1nZAxPgzR4m95vGsNgACdmFKF6jN3CTDgIAHC3t91AQc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782723442; c=relaxed/simple; bh=Cn0Hdsnc/OYau8eYKqRpxB5lCuUUIKG4vrn2ICVjz3Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lKo7HVgtvx1Lg3LbsmhdPDgvCTmE3lhjkfcR56JYnThhk1cwjNeSbMt6BsooyAYErmIyngHJ5dH3xJHNkcUW6sl9/cqKcgCXmZf0zRbhi6NYODU4e4yJS7kiLNmfazDHiIdfJ6nTXjGwJlNvBn6RWUxqN4sImEFe3Ocu+MJHMGE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=sang-engineering.com; spf=pass smtp.mailfrom=sang-engineering.com; dkim=pass (2048-bit key) header.d=sang-engineering.com header.i=@sang-engineering.com header.b=DAR6X1dx; arc=none smtp.client-ip=194.117.254.33 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=sang-engineering.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sang-engineering.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sang-engineering.com header.i=@sang-engineering.com header.b="DAR6X1dx" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= sang-engineering.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=k1; bh=kWrD HiKeyxwtEZPkBVnyaEj82oKV48RkCbwlxtlTE3k=; b=DAR6X1dxI+c9njC5WYif IKdw/eDXluaqJ7k+HnfoclL/TJkOCMhdY0VCxlNpKT1avqyoIh5z7VGZHkQLRj4x C74XKZNkQLLrxoMBQTQQVZd2j1uy3ySwYhHjFIHtsIYjFaRSDOXdHXp6WCCecK0P 3T4mcy9f5NCHnAj8apwJ0mGv1GInX3z4kWCa7dCaZNHzUdThyhk8SMRRnE/OcEz4 gEsbZQJC7qrncwjV5V12IAytX8fqDkirs3OInKMozLMAo28zy1awzSG3k/J0k+3W tuEF5C2YYK8Wk6/u5oeti7EdX7qr23GMa/daTPSKoZ/lmKKYJZwzAy6KujEhU6vD tg== Received: (qmail 307330 invoked from network); 29 Jun 2026 10:57:14 +0200 Received: by mail.zeus03.de with UTF8SMTPSA (TLS_AES_256_GCM_SHA384 encrypted, authenticated); 29 Jun 2026 10:57:14 +0200 X-UD-Smtp-Session: l3s3148p1@f4UIpWBVrtIujntC Date: Mon, 29 Jun 2026 10:57:14 +0200 From: Wolfram Sang To: Matthew Wilcox Cc: linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org, Andy Shevchenko , Bjorn Andersson , linux-remoteproc@vger.kernel.org, Baolin Wang Subject: Re: [PATCH v2 0/4] hwspinlock: add summary in debugfs Message-ID: References: <20260622085204.54248-1-wsa+renesas@sang-engineering.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi Matthew, > > Because the radix tree seems to have no dedicated tree nor maintainer, I > > suggest that all these patches go in via hwspinlock. This also keeps the > > dependencies zero. > > The radix tree is deprecated. I don't want to add any new functionality > to it. Here's a replacement patch to convert hwspinlock to use an > XArray instead of a radix tree. Compile tested only. Okay, seems to work so far. Thank you again! Will merge your patch into my series with your credits. Now I just need to wrap XArray into struct seq_operations. Seems no one has needed that in the kernel so far. Some comments and questions to get a better understanding. > From 8ec88ed466e8153f546f7e8e69193cd5389488ee Mon Sep 17 00:00:00 2001 > From: "Matthew Wilcox (Oracle)" > Date: Mon, 22 Jun 2026 09:38:30 -0400 > Subject: [PATCH] hwspinlock: Convert to XArray > > The radix tree is deprecated. The XArray uses the same data structure > with a nicer interface. The hwspinlock_tree_lock is not needed as the > spinlock built into the XArray is sufficient for all these cases. > > hwspin_lock_register_single() used to always return 0. Its caller > thinks it can return an errno, so I believe this to be a bug and so I > have restored its ability to return an error. I sent a patch for that previously and would rebase your patch on mine to keep the one patch per issue ration. > Signed-off-by: Matthew Wilcox (Oracle) > --- > drivers/hwspinlock/hwspinlock_core.c | 133 ++++++++++----------------- > 1 file changed, 50 insertions(+), 83 deletions(-) > > diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c > index cc8e952a6772..1dd68b8410dd 100644 > --- a/drivers/hwspinlock/hwspinlock_core.c > +++ b/drivers/hwspinlock/hwspinlock_core.c > @@ -16,7 +16,7 @@ > #include > #include > #include > -#include > +#include According to some quick grepping, there are 102 users of XArray including this header and 423 users which are not including this header. Do you think this is a useful improvement to add the header directly (per subsystem to keep the number of patches limited)? > - void **slot; Great, this obsoletes a fix concerning RCU annotations I have sent previously! > @@ -389,15 +375,9 @@ int of_hwspin_lock_get_id(struct device_node *np, int index) > /* Find the hwspinlock device: we need its base_id */ > ret = -EPROBE_DEFER; > rcu_read_lock(); > - radix_tree_for_each_slot(slot, &hwspinlock_tree, &iter, 0) { > - hwlock = radix_tree_deref_slot(slot); > - if (unlikely(!hwlock)) > - continue; > - if (radix_tree_deref_retry(hwlock)) { > - slot = radix_tree_iter_retry(&iter); > + xas_for_each(&xas, hwlock, ULONG_MAX) { > + if (xas_retry(&xas, hwlock)) So, the unlikely(!hwlock) case cannot happen with XArray? > - ret = radix_tree_tag_get(&hwspinlock_tree, id, HWSPINLOCK_UNUSED); > + ret = xas_get_mark(&xas, HWSPINLOCK_UNUSED); xas_get_mark() returns bool, so I will update the code to match that. Makes it more readable, too, IMO. The rest I could understand, I think. Looks much leaner, in deed. Will keep you in the loop once my next iteration is ready. Happy hacking, Wolfram