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 E9E3D2D9796 for ; Fri, 9 Jan 2026 19:27:15 +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=1767986837; cv=none; b=e29BOLlO25lyFW/N4lGDL6ypDo6elH/UKwRlAbzhJmdGUrJwXTggZUSAeQ8+57yob9Dh+AsIFIZ0Ok5UBRVGfJYwL823kTblu2I3deSnbK9OXhZYkvOl7uLeNOZarECtaoaJ/woC8Z32YDN6VjosTM4B+dtMpoGn0cjoTYmwhNw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767986837; c=relaxed/simple; bh=0JeBGnMkZoq4k4iygKGnfUdS/FhP2rN4hEUI+hrdfZU=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=fZ/JCHkmW36FIW8rlnfuODYb0sP32HADeePEHsnAc4HGMfhxdQT68FgI59SzinCCH5pF89XvsFn6u7PF+7/fG30hYpEHyxzTOocsYHxlECrsnriAI2byEPCLjKjvnZeDTOIkmtTu6Ov5gzR8GAhDBhhGvkgNJGmQZo3OxdaqGsg= 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=ObCNvE5Y; arc=none smtp.client-ip=209.85.128.41 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="ObCNvE5Y" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-477aa91e75dso4646705e9.3 for ; Fri, 09 Jan 2026 11:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767986834; x=1768591634; 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=+yRRp6qL46Mg9PzskwLIpsttG5X3LuZFRlUU9buwfQ8=; b=ObCNvE5YLEbHUzJThyJRKjUEJ3V+Dba3wtyU8bVhYOYjc2aPQWXXYbr32/tMCbLUVA 5Izcs/Pf0fP+Y6uq/rA59HX3sds7Uz91GD+3bSs9cFvZTJNFxK8MrvgMlqN2DbnwVZ9f csgGCTT/01nkABkv9kzCYweK0xTooug1ChyxUzrrvnyQZZa8rWWoBEjDXEb2CMCSbtX+ 0+afUsU0EJ3OEN5wNiy+K9iEZwhKUifmZDPfi3NnFyTKDJtMODaTeNc8SuqFU+JGc35M qQWjOoxFIIvLuMzfMwomnII+1qQXlpOWARdb0nToZGVMh8IagXQpgCQ8y00J6uJEHomJ aPHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767986834; x=1768591634; 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=+yRRp6qL46Mg9PzskwLIpsttG5X3LuZFRlUU9buwfQ8=; b=dA8Zn+b6fR1tmhsBcUypON/L+vPa5mAbdeAOwrlgWlT21szIdemAnN/ICNwrfH8mJ8 bo0wIZRMNFk2uKGPrT3N9eI8EWkNnYmoyHge82qaMocwUbCy3GPqjwsuRC6hSHubS1M/ G2qTDmXadT+kwkjnBpwEwWlomKqLmhbiSRmFFI4Veh/SwBsrLsMKvxvyUYNgdSd4h/Oq 35zLjoocqsy9HmjbydYW9LozUYYEpc/VEkuARADrJFhiaL63fxPePhlhOlwpMxxpInDt 1ZbG9oDhux/hfdGRCrbJhNvtn044mMJQxE4zosNRJg7I74jsdYonXfYBsErm1elx7HP+ O2MQ== X-Forwarded-Encrypted: i=1; AJvYcCU3bign6hKVOc+9JattUzgievMaLBooGsjg/DMfSqNHz6TgvbrHYFUeJ1XjdFdEV6hegstJQj/Ru+TarFc=@vger.kernel.org X-Gm-Message-State: AOJu0YzmFZR2LrW24hbKbVL09O5ENMQJ3C2IdwJ2Q+iVE2Suf2DAh9Fs V3YUKKmOw+9AItB9PU7PyGOz+dDdTKg8qvjDnH7u/an3sSe1ZY5qlt+6xysksj1BIgE= X-Gm-Gg: AY/fxX4qZxRJJiMRzH4Fb63hzbPIMShrwCVD5VfpiJ9yHQxisp/87WzonnJH62oXTDn 2Ui3NaLOwieiACjV04JUliEZnq6ED5CfPYi+MDvYSKGGQIUAFTTl8litEAn5u5YZP+wZ/cY/Uwl ljccLTH431b3DlG2jKRUip+6YS1hab3Xerm8R6G4VkEWWJfd4nuysfFgA4qUfRFmPFs9Xf1c6EG /v61GOEKtSKGJJjop0iUrXMQqNR2dDuwuEc55fcRyCORY2Q1XQyAi1+x6Uu8F2X9TqbdnoRufcS Npwolbx7Eu18y/JgEUsAjUlLvqA2R3I8lq8lgE2C/oGqYbuQ2pm/oWhm7BR1LqnT33i3Gy4LbGj B0onG5t2+FIIh6dn2E7FcTPviUTRDVHBwiXWNoWpcREUjXXHNHSZop64X7SbQGERcRuY3kA3qeU 3jA/hw+3bN0AsyFN1A04diqwO1OVM319DgkvILKuqGEUlnHv6ThpXFg01OwxtXO34Udkfzqi76x Df2 X-Google-Smtp-Source: AGHT+IEWxxsjfqA65aNyEoZL3BHgiswdeN7TcCl5b7JrqcJSk22e+RxIYZM5RWMxzHd9NnuS4NR6EA== X-Received: by 2002:a05:600c:470c:b0:477:a450:7aa2 with SMTP id 5b1f17b1804b1-47d84af32e3mr75139665e9.1.1767986834160; Fri, 09 Jan 2026 11:27:14 -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 5b1f17b1804b1-47d870dd5b1sm76883985e9.4.2026.01.09.11.27.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Jan 2026 11:27:13 -0800 (PST) Date: Fri, 9 Jan 2026 20:27:11 +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: <20260109202711.5f356b3e@mordecai> In-Reply-To: References: <9767487fcab7dbe7a7282a48a492171629eb935b.1767975412.git.ptesarik@suse.com> <20260109184614.7b3b9bb3@mordecai> 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 13:26:30 -0500 Yury Norov wrote: > > > No need for a separate header. Just put int straight in bitops.h. =20 > >=20 > > 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 . =20 >=20 > Unless you have strong performance numbers, let's keep it in the > bitops.h OK. > > > > +/** > > > > + * 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. :) =20 > >=20 > > 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. > > =20 > > > > + * @x: the value to search > > > > + * > > > > + * Unlike ffs(), which returns a bit position, ffs_val() returns t= he bit > > > > + * 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? =20 > >=20 > > 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." > >=20 > > Besides, this patch series does not change anything, it merely puts the > > arithmetic inside a macro. > > =20 > > > > + 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(). =20 > >=20 > > 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. > >=20 > > What about isolate_lsb()? =20 >=20 > In bitops world, something_mask() has a very clear meaning. Consider > GENMASK(), BITMAP_FIRST_BYTE_MASK(), __BF_FIELD_CHECK_MASK(), and so > on. >=20 > lsb_mask(), or LSB_MASK() if you prefer, is just right. I assume you mean BITMAP_FIRST_WORD_MASK(), not btrfs-specific BITMAP_FIRST_BYTE_MASK(), defined in fs/btrfs/extent_io.h. But then it nicely illustrate exactly what I mean: BIT_MASK(4) =3D 0x0000000000000010 GENMASK(4, 0) =3D 0x000000000000001f BITMAP_FIRST_WORD_MASK(4) =3D=3D 0xfffffffffffffff0 > > The only issue is that LSB may also refer to least-significant BYTE. :-= ( =20 >=20 > It will never mean byte because it hosts in bitops.h, not byteops.h I'm afraid that identifiers from various sources end up next to each other and they do not carry tags where each of them came from... > > > This is also a replacement of BIT(ffs()), GENMASK(ffs(), 0) construct= ions. > > > 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(). =20 > >=20 > > 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. =20 >=20 > If you don't want to fix every driver, it's OK. But please keep core > kernel clean. Yes, getting acks from all maintainers will take a lot of time even then. Again, thank you for all the tips! Petr T