From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (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 4593A3563E3 for ; Mon, 12 Jan 2026 11:22:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768216930; cv=none; b=jYXDagvJih/TMcfxb6a+Z3WOJ8tYh+kzfOA6Ys4YbRHR/f0kf39z8Pdwubv6OPD1qg9/OBte++4Mg6vAtXFu+MhpAtTLnGbsQlromaUtVxIDfUJF+WAST0fmzMNAAESETPg7Jr28O3e5MHY6EQRtFi4Z7w3TIJiSTLhW5UNJyI0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768216930; c=relaxed/simple; bh=jJNh+mY1zBXoPENkMgwDv8tHvtTQopvo8nwTkVA0sa0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FH/bUL4wI3+gjeVnDPFcOZ3vAEJiV0BC+brtTHw/RRyLGsEiIez70z49W3J6I2xVVqvJRxDhsXYpcEWsF8jtQsr7f6JIWlqyUn8ESM7tMTkVVUK23ZwOH4JC5JrmHyD7pKwhbBqILTqztJxaX9qc0tI29HJalJaYprVEIuOn0C0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=iFxab5Sd; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iFxab5Sd" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-47d63594f7eso37309445e9.0 for ; Mon, 12 Jan 2026 03:22:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768216926; x=1768821726; 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=K+/WM3an9TOxVHNMlX7rGNVcCDxHea35cBtjcw/EUs0=; b=iFxab5SdIxAUm3gtY0uyPA4reQMU7rjFeCB5L4mehMiKnczGhSYhmVexOo3KjSR74L SjsZVU3C/ZdJ/beIlvvXLHRF1Yspk8RjAw82OhWBqF7OKoNj6EK1XF/I3QdZcbCQAeUI qQt1vsjAmdtXuJKNfK50VD7dfBvfVKILkQYLIGKL2V5yhCfhDmzLUP4alz+2WQ6qCgJs Fjegx9iZzXASBBrk1fDmz3iHPZwC5mT5FKj2YxNFsLHIFnvbnGJmQq0pFtnX7IUJYYMI LQ8miT/FDUkJOoPkbdzzp6qbBFxnb3E8u9wjAX2UiC8n5JlkmEcaXWw5Aq+4nj4quPGY pvew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768216926; x=1768821726; 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=K+/WM3an9TOxVHNMlX7rGNVcCDxHea35cBtjcw/EUs0=; b=ezrv2OvGzqkgaNjZgsbSmiddiNmqf0Hz0AwVS1PnxYkh0vdUWVxFPFbInqa8hY/o11 B8eSuAonhZISdtE3kGpu+qG2hGrotTE7GHCoY8mo637/D28n7jkWnFxdgqR7exVi3Hm2 TdPZyRfYCdSBmtALWy1bUYTO0kQ7++1uJlhMENyCVzLNR7YjgpuKTBOMZnSgpehgltmI 9HftnLBNp3ZAzpw7vwE/BtgZM9wKayJQoJpzUmXkJmrGMoL80ueG8Tx6ChVj5wIPSFJC jiJreyN1k/dt2Dp9KOWeJQAfLvUqSB0mNH01ppeCyJA+ViMNXthRPdYlyVC8Cqp+z2ku 4rUg== X-Forwarded-Encrypted: i=1; AJvYcCUv7uPhw4jxpRbuP2cXT7ceFBWevFk7OQgf+CLt6xMEuNakDvPOxhMWaA6ldaI2YnP7UuLsA1DCgqsW94g=@vger.kernel.org X-Gm-Message-State: AOJu0YxH/A19U96bKk4vFPeoxtGjbf2gEMSpjzN628LMGRaYRS2QETHT a3OdsOePHV4Ax/+AEGm6FOVbL5NN/N8QsTYM80/klHCZ40pR3vQAVSTf X-Gm-Gg: AY/fxX60unsbdPbt6gu5gNsBSOC5lAYg0RjsuGKUiMfQNrF4KXe/bwlT+ASB3Bq2sdC OrEvHLIpF7l0bEHRx/4x700pimfNfH0hjf77yYL1agXEd3Cm170F+gz1cJf7sRbu3BCjUzYZ9C4 dpNxlAbMcQf1ZnCns+MnbeTNnJP0EHtW1XUeK+1t5rwWKW69mYHPqvcDyz8dsmfDHiXVKVXJaVO GNR4tG541U794lm3GnQXurw1Kv0gfgIhvOyLhx+wLWzPIS9/aeP6rQ3DrS4IB3UTnTOaJgvbcp9 Ex42gj5dddI+9Pekb9sFglLtJrnM0nt3d0uolcTlDchmdTToQyZ1EwSv20XwRWfIHv00olORHrz VzXwd5T+oAwYDLNdc2L+caZpS3zf/tk5qfuCfzxlWin00svadBSjPiQxDIjgJYpCGqpJCQMSZr3 M9/7YdIG80dnC7COXp4eI+lFfEjgLpILc2CIUh1e7S21n9d+TnSv2wEHw0CeaP/3k= X-Google-Smtp-Source: AGHT+IGRmd5r49kB0K58+fyTetX1gDZWPU5PQqFZj7Bf0bZItLVPW5Z4fLYuHV0F2TyRHikdFFce5g== X-Received: by 2002:a05:600c:1d19:b0:47b:d914:98a7 with SMTP id 5b1f17b1804b1-47d84b3b65bmr200517865e9.29.1768216926326; Mon, 12 Jan 2026 03:22:06 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f390a69sm346525975e9.0.2026.01.12.03.22.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 03:22:05 -0800 (PST) Date: Mon, 12 Jan 2026 11:22:04 +0000 From: David Laight To: Thomas Zimmermann Cc: Petr Tesarik , 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: <20260112112204.4dc7a3a5@pumpkin> 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.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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.' An example would clarify things massively. Perhaps ffs_val(0x40100) is 0x100. > > + * > > + * 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. Writing as 'x & (~x + 1)' makes it pretty obvious that it is always valid. For two's compliment '-x == ~x + 1' and the compiler will do the transformation. That expression would also be valid for one's compliment and sign overpunch systems - but the result for negative values might be unexpected! OTOH I'm pretty sure most modern C code assumes two's compliment binary numbers (and NULL being the all-zero bit pattern). You'd have grief trying to compile C for an ICL System-25 - decimal/BCD numbers with sign overpunch and addresses binary_page * 10000 + BCD_offset. (Still in use in the late 1980s.) David > > Best regards > Thomas > > > +}) > > + > > +#endif /* _ASM_LINUX_FFS_VAL_H_ */ >