From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 263A4345CC6 for ; Mon, 12 Jan 2026 08:58:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768208290; cv=none; b=IIJKyZnCggBA2MestYaMwxobMbrbmXNNPVBJ5rHP/gkJZk39fWirM0uvZEA6RwSc2AP/04TV7kWZPaEOuTah9gT6Rboq7KD7d2+9t62LF+4PwoBMA5rUP9lcKJ+dw+z+g+t2GoCYPo8HjH+x9c4QAq4nJWmbIk/i50ymUwy+OEE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768208290; c=relaxed/simple; bh=gKp+N5XiaUsMHpj51FvmUjLPjqt+F+LXWYD+csu7lxw=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Yu645489XG3My0qDcGc1eORUaIY0JyOZ8j1jmmidyz6NCOCzgvxB+bvB9uVb61mXgIypmZFmMME2QQ9YPI/lBvle9jMEHQ7lk95FKWvvmrygARI4+GYcFOx9Di9qpp871a0qywxoTk2sAnmQ/3e1hq+F9lwz8V5mTpv5YXlEUk8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=Jew9cJOI; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="Jew9cJOI" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-47928022b93so12658785e9.0 for ; Mon, 12 Jan 2026 00:58:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768208287; x=1768813087; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=q/7s34Rlg+4N2yemKbbTf/deKzB/FqvJDWxtIhyznLU=; b=Jew9cJOIDvny2hyjy85ywRsbO4EtjJcodxZDO1lfzVSTGWTDsOY8+pbq9mos1KPuta VWSSMZzgdN8X2BCUgZhSNIGauOKirx6kuCSfLF4Ry8uJ1CwRbwcdbTBhbJnSJYXqoaS/ kifqp3b2Pqacz0yBXAtXCMnVQm7DrCmlpZUe5xirBF5Z9OF1zwSD3ROiop82tuQAr4p4 tZLZMUfF+wqfv95jEuNUzGcSacrYdZAq6SiQtn1WwYctmjGh99WATHm+s1Aa7eQhUpS4 +yx8RLA9ZOz+HdKAZGdoIM3jwBjpWQuZxwRuPHBCNP9+iyI/OOO4/6qLfU3QW+WG6VYz zLyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768208287; x=1768813087; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=q/7s34Rlg+4N2yemKbbTf/deKzB/FqvJDWxtIhyznLU=; b=A4Ppk8vyWPH8fO/S6t6ybeGI3WYjlPdMO1QvvdzjPk2kALI274m+QlLKXubNKSDmTd 1gxUygy2o7AytyEr3pRMj2FhVh2mDu/U9ZdRC+UQWtapk2HJVyln+ebpgCiUNgxKH48M tNFN28dtkKKzHJh5Esv1CW8XsZ2CLDPySFeHukK2MouWR8yRULnxUqd7flw4PJ6eKvG3 iM7kmMhQ2S+q4Ajzp0sOLBj/D59VjpzK250CRhfa3G6Qnj2ngwQsgiXrBo8bLfo2cCnw WwuvjHPFHLFxsQce0BHw8vIAHF2MMNz9A+S0BLfMnW89+Y10e/k8EjH/rjHfY0AoKBhY utdg== X-Forwarded-Encrypted: i=1; AJvYcCXtLBkUuICKs7ScwR0ZJE8PGo4qJQ6mGn+pZkcBM/Nymxom2xMOl8/QXd2OAXqey8pFCzyYLp98w9suTPc=@vger.kernel.org X-Gm-Message-State: AOJu0Yy/yJVc4ADsZRZE+FBCgswyvlxxleayEkea051Beq5fcsLL9uqk aRzrMurAp2FmEPBTXpqgHQjSq1aTnq2455AicjfDf7rXfTP1fGQSqzlOL0M9tutVbPs= X-Gm-Gg: AY/fxX41iMu5gZv03S60V+IqdZ9lfxO2X8OTajTRHJsD89ACHOE+tUQ0rWBSUqVka7h N1E/Ci0uQSaXrc0432yI1vfz69QlDSX44GA7CzGHFTDfnBsRt/EB8VZVpqMChY3F+P01Y/5OkPD gr+rLNMttf2QfJRecyCaQxpDQSS4QG1t70JIC2vKqWjjT2qSVnl+dy8j3YBzz9pTKCuH+kSv79U RRynBMIVwYHiV1Mc3s19DMaZhfdaI3/dze5vwt+/zGsakiNnVD/1Qfb45GjXKo7NhEZwJY1bQeA SLC2geBcT4serPTzPToSMGmo/fvrIrTqIIf7kXizI0iaxj0xHpCsiAF/b89Lj6dWMYmX0xhb5WG tEyU+DaefdJl2gHe1AWAkKT1K61Duzj9gdHArie5rrMps3vfA1FQZrbZNcFbc+xd9ueBJHKePnN zVVnzFHNijYb4OAz/9PwyVQgeDHAufjzYs7y+XMCM94YyssChP8yuaMB+poBTRLmAuxIro65zVk NJO X-Google-Smtp-Source: AGHT+IEZ1RGFmEjHgD5D6AU3UkaoWixJ4wgtDPEDT3c1YqOXJsytt12qz8+qm11nbX0Ya8ytyN8uig== X-Received: by 2002:a05:6000:4024:b0:430:ff41:5c95 with SMTP id ffacd0b85a97d-432c39d2cc8mr11987511f8f.3.1768208287302; Mon, 12 Jan 2026 00:58:07 -0800 (PST) Received: from mordecai (dynamic-2a00-1028-83b8-1e7a-3010-3bd6-8521-caf1.ipv6.o2.cz. [2a00:1028:83b8:1e7a:3010:3bd6:8521:caf1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0dadcfsm36948438f8f.3.2026.01.12.00.58.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 00:58:06 -0800 (PST) Date: Mon, 12 Jan 2026 09:58:03 +0100 From: Petr Tesarik To: Thomas Zimmermann Cc: Yury Norov , Rasmus Villemoes , Richard Henderson , Matt Turner , Magnus Lindholm , Vineet Gupta , Geert Uytterhoeven , "Maciej W. Rozycki" , Thomas Bogendoerfer , Madhavan Srinivasan , Michael Ellerman , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Chris Zankel , Max Filippov , Patrik Jakobsson , Maarten Lankhorst , Maxime Ripard , David Airlie , Simona Vetter , Robin Murphy , Joerg Roedel , Will Deacon , Jakub Kicinski , Andrew Lunn , "David S. Miller" , Eric Dumazet , Paolo Abeni , Oliver Neukum , Arnd Bergmann , Kuan-Wei Chiu , Andrew Morton , Marcel Holtmann , Johan Hedberg , Luiz Augusto von Dentz , Pablo Neira Ayuso , Florian Westphal , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 1/2] bits: introduce ffs_val() Message-ID: <20260112095803.5c224905@mordecai> In-Reply-To: <9c61bd17-bd42-4641-a118-9114a5ccdc13@suse.de> References: <9767487fcab7dbe7a7282a48a492171629eb935b.1767975412.git.ptesarik@suse.com> <9c61bd17-bd42-4641-a118-9114a5ccdc13@suse.de> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-suse-linux-gnu) 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-Transfer-Encoding: 7bit On Mon, 12 Jan 2026 09:15:41 +0100 Thomas Zimmermann wrote: > Hi Petr > > Am 09.01.26 um 17:37 schrieb Petr Tesarik: > > Introduce a macro that can efficiently extract the least significant > > non-zero bit from a value. > > > > Interestingly, this bit-twiddling trick is open-coded in some places, but > > it also appears to be little known, leading to various inefficient > > implementations in other places. Let's make it part of the standard bitops > > arsenal. > > > > Define the macro in a separate header file included from , > > to allow using it in very low-level header files that may not want to > > include all of . > > > > Signed-off-by: Petr Tesarik > > --- > > MAINTAINERS | 1 + > > include/linux/bitops.h | 1 + > > include/linux/ffs_val.h | 21 +++++++++++++++++++++ > > 3 files changed, 23 insertions(+) > > create mode 100644 include/linux/ffs_val.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index a0dd762f5648b..8f15c76a67ea2 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -4466,6 +4466,7 @@ F: arch/*/lib/bitops.c > > F: include/asm-generic/bitops > > F: include/asm-generic/bitops.h > > F: include/linux/bitops.h > > +F: include/linux/ffs_val.h > > F: lib/hweight.c > > F: lib/test_bitops.c > > F: tools/*/bitops* > > diff --git a/include/linux/bitops.h b/include/linux/bitops.h > > index ea7898cc59039..209f0c3e07b9e 100644 > > --- a/include/linux/bitops.h > > +++ b/include/linux/bitops.h > > @@ -4,6 +4,7 @@ > > > > #include > > #include > > +#include > > #include > > > > #include > > diff --git a/include/linux/ffs_val.h b/include/linux/ffs_val.h > > new file mode 100644 > > index 0000000000000..193ec86d2b53b > > --- /dev/null > > +++ b/include/linux/ffs_val.h > > @@ -0,0 +1,21 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +#ifndef _ASM_LINUX_FFS_VAL_H_ > > +#define _ASM_LINUX_FFS_VAL_H_ > > + > > +/** > > + * ffs_val - find the value of the first set bit > > + * @x: the value to search > > + * > > + * Unlike ffs(), which returns a bit position, ffs_val() returns the bit > > + * value itself. > > This sentence was confusing me at first, because the individual bit's > value is always '1'. Maybe say something more descriptive, such as > 'ffs_val returns the value resulting from that bit's position.' I think I found the best wording only when composing the cover letter: isolate the least significant set bit. I should have gone back and adjusted the patches, too. > > + * > > + * Returns: > > + * least significant non-zero bit, 0 if all bits are zero > > Same here. > > > + */ > > +#define ffs_val(x) \ > > +({ \ > > + const typeof(x) val__ = (x); \ > > + val__ & -val__; \ > > Is this construct supposed to work with signed integers and/or negative > numbers? I assume that two's complement can be expected nowadays, but > for LONG_MIN it returns zero AFAICT. The documentation should mention > these cases. It works fine for all numbers: -LONG_MIN is LONG_MIN, and that is incidentally the number with only the least significant bit set. But this is all moot. After reading some other replies, I'm not even sure, this helper adds any value. I'm going to start over by converting occurrences of x & -x with the most suitable existing helper, and see if there's still some value then. Last but not least, if there's no good self-explanatory name for this operation, then I'm told that open-coding "x & -x" is in fact easier to read. Then again, this is the opinion of people who coded back in the 1980s, and my general feeling is that bit operations are generally less well understood by people born after 2000... Glad to spark a bikeshedding flamewar, anyway. /s Petr T