From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 DE08E20E025 for ; Fri, 9 Jan 2026 17:46:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767980781; cv=none; b=f8ne0gDrgzozPCB3aAQFodWG3hqqRcx5unmf8N8Dw1OZw7KPlLbHQVwaTjGtf5dNHGu/2iS8WilVNafxXlcUWznDNmM0GKflxS7AumiyDkuzXaNby4baICxppYfJpB98d9uK1X8Z/DfHUn/6w7n3+48VCRcCF4oJXOk97J4dglY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767980781; c=relaxed/simple; bh=HYHBKE3nxaIBbQxV732UOhIIAFvZL2M+DcE6Kx2D7vU=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=aLRQ0jrJY9oUz7YRZaARis89Y+opq0QTnuPB3mjoJaxlj1RpvygYD7jFn++7gSIm9u9VJnOAAwLWKCeeaoNs9P6qSnJXqlbcZVo4Ho46dJCgulT5P6SS9tvdJJ61t9fpif8hraJulzxNGUNu6UeRTCJcWebkhC5sSuSZ8rhRjB4= 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=InjyGLR9; arc=none smtp.client-ip=209.85.221.44 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="InjyGLR9" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-42fb8aa0c3eso408058f8f.3 for ; Fri, 09 Jan 2026 09:46:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767980778; x=1768585578; 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=T5/WtbFj3gTge7fX2RPV/lk71dENBWzTtsgWfCrhUT4=; b=InjyGLR9AfatKRYloF93Y5h05hKwXaIq6PG+8Q0shaORvA+WZAbyz3Dk4GJL29w/eu BByBwuWonxQBTwkNSo10baztiRCmISofm1CzCXtxHTL+XljM5M+4j26z2Yba49nES1O0 7Onup34Ml+hbN7oNFc0FFNql1QsanSNKwDcZH9jOrnE+BR+8lw54ChiOz+eMGpS0zEEZ u3zRS51s1xAoCN1Wx0vBvrWnDuICGnMXvA9+X8zS8CkCwrYOoOq1dEsAWvgEpuM5Frff afTqgfe1I19vTCxjBO55yqDxJvFP15fbAx+jlM6dnFEwO7f1dLYHnqoxJmnXltPLhexe p5cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767980778; x=1768585578; 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=T5/WtbFj3gTge7fX2RPV/lk71dENBWzTtsgWfCrhUT4=; b=P9l95Ebarg6dtCsZAL34h+i+pfWhqKU48kTfvvekN0+tsz2jiiz9q61eeOnLlWSRqj Qwg9HXV2rWkhBb9Kr9R9WvspfpLTYANeVuq6f7/jNNePc8RLidGJTFcRuXWQ2RID8ISM kjFL1uHx/IMB9JkfGZDqU5lp3N81rts86nnDhjBadANWmbQ4Ne5UVeT4xFVsDAVjrirE 8KzdPEGM3fFZ5U19EW2AJ7epJ1cvPp95ElToMRVQ3f2fqxp9V7ag7p/yS16vuWFX7YnP /9c+IUgZL0xYXqTw+F6NmRbQHR7Ulr46CXK6aUtLZgqPKLuaeUlUt2R46qCG10wvq6VC w+8g== X-Forwarded-Encrypted: i=1; AJvYcCVZjZ5v9WIToLLHe189YtS0IFMt5C37fIjdQ+byAuGTgLRb3Mcviq1Xm7b6ZpoIXQcD0eBHEnXXeATkPJo=@vger.kernel.org X-Gm-Message-State: AOJu0YwZL6xBqfeyjDIyzsNSH81myqXBrPv3vWpa465WR25d7gXus96V IiH3cFxumsc18iJLqydMkOtWN685PddgE79OgkB5RoRshYRJXXJ0G+7iCEwcG+0wiCw= X-Gm-Gg: AY/fxX5U/6O0XEzd4uPX2M/5xrji7ZZ7kKz0sEXtEGZOOKyjMZ4sAma4rD25OpyJFX6 BuG3bwesrUrlBybmrCBt12lfcbL3l7lLB/6LpXtvSea2fIZXoHQZ5l2mN35FOoz/AS7li2K75nq PQWJRJyeLXPeodu8X05f7oC1RgdvohC7oGuEFLCNH6qAiAo2kMohfA1m5Kh3liT/iPRqIJuYb2S aY3cAxjsgzZO9mM7LImzZC4LDcxf3RuvuxsXUXTIhdtDhSarHI8zzYuk3La/BtbarFqkX/xNuo4 pmdzUNnKHwRbIrX3HE2MZDToXCoHIsBfwIt4A6n2FtfeuY0yYnfWmQJphAucqMI5wAxUHobITZH 4Kzr9UtxU4EDi/4sM1HAaWn+4Oxwyb9VLnKNqqQ4IoIck/xn6KdvzGsBwrO8lYzSeRyRPSWfQGJ buKog8sUq6FeRP+COwpK+2dmKGOq3WanZ2Ynml+itVbJQpltIY5sM/TsdoBCCwPvp0R3cC7wsSO d4K X-Google-Smtp-Source: AGHT+IHVFlh2RJVPjIAYBzYKCGLTCUpp9Qwow3ita+p/8Kr4/KwYftkgAflIf8wdXrUq0NLUh9zIKA== X-Received: by 2002:a05:6000:22c7:b0:42b:2deb:829 with SMTP id ffacd0b85a97d-432c379ccf3mr7070493f8f.3.1767980778011; Fri, 09 Jan 2026 09:46:18 -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-432bd0dad8bsm24078733f8f.8.2026.01.09.09.46.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Jan 2026 09:46:17 -0800 (PST) Date: Fri, 9 Jan 2026 18:46:14 +0100 From: Petr Tesarik To: Yury Norov 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 , Thomas Zimmermann , 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: <20260109184614.7b3b9bb3@mordecai> In-Reply-To: References: <9767487fcab7dbe7a7282a48a492171629eb935b.1767975412.git.ptesarik@suse.com> 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=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 9 Jan 2026 12:16:06 -0500 Yury Norov wrote: > On Fri, Jan 09, 2026 at 05:37:56PM +0100, Petr Tesarik wrote: > > Introduce a macro that can efficiently extract the least significant > > non-zero bit from a value. > >=20 > > Interestingly, this bit-twiddling trick is open-coded in some places, b= ut > > it also appears to be little known, leading to various inefficient > > implementations in other places. Let's make it part of the standard bit= ops > > arsenal. > >=20 > > 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 . =20 >=20 > Nice catch. Thanks! It's been on my TODO list for months, but my first attempt failed because of a coccinelle bug, and then I never got to it again. > > 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 > >=20 > > 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 =20 >=20 > No need for a separate header. Just put int straight in bitops.h. Well, is a bit heavy, so I was afraid of spoiling build times if I include it from , but if you say it's fine, yes, why not, let's put it into bitops.h somewhere before #include . > > 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 @@ > > =20 > > #include > > #include > > +#include > > #include > > =20 > > #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 =20 >=20 > By definition, the value of 1st set bit is 1, just like any other set > bit. :) I'm struggling with suitable wording. The trouble is that "find first set bit" is generally understood as find the bit _position_. Maybe I should say _isolate_ the bit, or something like that. > > + * @x: the value to search > > + * > > + * Unlike ffs(), which returns a bit position, ffs_val() returns the b= it > > + * value itself. > > + * > > + * Returns: > > + * least significant non-zero bit, 0 if all bits are zero > > + */ > > +#define ffs_val(x) \ > > +({ \ > > + const typeof(x) val__ =3D (x); \ =20 >=20 > const auto? Also, are you sure it works OK with unsigned types? No > warnings? Maybe add a test? The "const auto" is good idea. Regarding unsigned types, indeed, the result of applying unary minus to any non-zero value is out of bounds of an unsigned type. However, the C standard has this much to say: "C=E2=80=99s unsigned integer types are =E2=80=98=E2=80=98modulo=E2=80=99= =E2=80=99 in the LIA=E2=88=921 sense in that overflows or out-of-bounds results silently wrap." Besides, this patch series does not change anything, it merely puts the arithmetic inside a macro. > > + val__ & -val__; \ > > +}) =20 >=20 > This macro returns in fact a mask containing LSB only, so I'd suggest > to choose a name like lsb_mask(). Mask is a terrible word, because it doesn't say if the masked bit is set or clear. Even if I limit myself to the Linux kernel, it's used for both in different contexts. What about isolate_lsb()? The only issue is that LSB may also refer to least-significant BYTE. :-( > This is also a replacement of BIT(ffs()), GENMASK(ffs(), 0) constructions. > Can you check the kernel, and convert those patterns too? I found at least > one in drivers/clk/nxp/clk-lpc32xx.c:lpc32xx_clk_div_quirk(). Yes, there's a lot of places under drivers/ that can benefit from this macro. I didn't want to spam everyone with this RFC, as we iron out the details. I'm even unsure about the correct process to get such a change into the kernel. Thanks for the review and suggestions! Petr T