From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailtransmit04.runbox.com (mailtransmit04.runbox.com [185.226.149.37]) (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 365093195E8 for ; Wed, 26 Nov 2025 10:38:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.226.149.37 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764153538; cv=none; b=gyb7W2nA6isj9LJb8KK6Yz9R6JemqNpAsdCGtHDgKDCCc813OJVuErGhCQIjW7NBBjQDA1HDAOuUce5mu/zsNiSgYhmI5P1psDkbNFEaxQRUMCD46p0u53PoeNE9p8vKxwerRAuOIrxjuia0EoNf47hzx5tjUZitk3vLZSCLtSo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764153538; c=relaxed/simple; bh=2iNWnJxawKQ4VBAm3ocASqLKodPkZi8QZyckJR6wSV4=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ccnZok+JA5Oj7Dqt3j91w4ykammPbYKKGXyK2uOB2R8qXbl0FedpZ0xBXT6wVaws2omEmurwyxu11V/pL/2i79bwmjddWVhmoCED0EreDA1xmg6q1LUmaV1oFVNWtZlctB2Z+hdfUn+0Z13wbl6p7tXNn/SXaxMe3TnJYUCCevg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=runbox.com; spf=pass smtp.mailfrom=runbox.com; dkim=pass (2048-bit key) header.d=runbox.com header.i=@runbox.com header.b=LK4y6uAj; arc=none smtp.client-ip=185.226.149.37 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=runbox.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=runbox.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=runbox.com header.i=@runbox.com header.b="LK4y6uAj" Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1vOCv2-0099ob-QC; Wed, 26 Nov 2025 11:38:40 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=selector1; h=Content-Transfer-Encoding:Content-Type:MIME-Version: References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=nUL5I0s1QEiuiBfJrwJvCcOavCb8frTd3cdoZ30dxes=; b=LK4y6uAjGPNR1Keb53zxzuQzri fnGt+XDkm6DeoOrB08wxnFtR4uA1jZ7VSP3w/WnXcI19jA3qbQFSQs0JJG/karIZK1JqyN3N1rRvo rtBLLnpzcF7GVRbTVqCg8+tOmqD64O62kDjPtOXLQPdnBHNbZxWo13TaYyB6iuNPa7ZE9k+OCHuud twSHbx6dXTgjH4QOQYha3zFveB8ZzX9gLXtM9kdh6I+NT59JqThZNwx3f6yV/XOil1c7uFc5VeXf/ Hsg9AbYJ1OrFYQLmVtTO5R6Vm2TZUI+qI25+DwCnARV3z/1+3hUWeIPLZjimD8kiiZYQ3m8oMMUDw jTQM+R9g==; Received: from [10.9.9.73] (helo=submission02.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1vOCv2-0008Rk-9O; Wed, 26 Nov 2025 11:38:40 +0100 Received: by submission02.runbox with esmtpsa [Authenticated ID (1493616)] (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93) id 1vOCv0-00EX15-1j; Wed, 26 Nov 2025 11:38:38 +0100 Date: Wed, 26 Nov 2025 10:38:32 +0000 From: david laight To: Rasmus Villemoes Cc: Linus Torvalds , "Yury Norov (NVIDIA)" , Linus Walleij , Nicolas Frattaroli , linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/21] lib: add alternatives for GENMASK() Message-ID: <20251126103832.6581bbc6@pumpkin> In-Reply-To: <87ldjtuppl.fsf@prevas.dk> References: <20251025164023.308884-1-yury.norov@gmail.com> <87ldjtuppl.fsf@prevas.dk> 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 Wed, 26 Nov 2025 10:07:34 +0100 Rasmus Villemoes wrote: > On Sat, Oct 25 2025, Linus Torvalds wrote: > > > On Sat, 25 Oct 2025 at 09:40, Yury Norov (NVIDIA) wrote: > >> > >> GENMASK(high, low) notation reflects a common pattern to describe > >> hardware registers. However, out of drivers context it's confusing and > >> error-prone. > > > > So I obviously approve of the BITS() syntax, and am not a huge fan of > > the odd "GENMASK()" argument ordering. > > > > That said, I'm not convinced about adding the other helpers. I don't > > think "FIRST_BITS(8)" is any more readable than "BITS(0,7)", and I > > think there's a real danger to having lots of specialized macros that > > people then have to know what they mean. > > > > I have an absolutely *disgusting* trick to use the syntax > > > > BITS(3 ... 25) > > > > to do this all, but it's so disgusting and limited that I don't think > > it's actually reasonable. > > > > In case somebody can come up with a cleaner model, here's the trick: > > > > #define LOWRANGE_0 0, > > #define LOWRANGE_1 1, > > #define LOWRANGE_2 2, > > #define LOWRANGE_3 3, > > #define LOWRANGE_4 4, > > #define LOWRANGE_5 5, > > // ..and so on > > > > #define _HIGH_VAL(x) (sizeof((char[]){[x]=1})-1) > > #define __FIRST(x, ...) x > > #define ___LOW_VAL(x) __FIRST(x) > > #define __LOW_VAL(x) ___LOW_VAL(LOWRANGE_ ##x) > > #define _LOW_VAL(x) __LOW_VAL(x) > > > > #define BITS(x) GENMASK(_HIGH_VAL(x), _LOW_VAL(x)) > > > > #define TESTVAL 5 > > unsigned long val1 = BITS(3 ... 25); > > unsigned long val2 = BITS(4); > > unsigned long val3 = BITS(TESTVAL ... 31); > > > > and that syntax with either "3 ... 25" or just a plain "4" does > > actually work. But only with fairly simple numbers. > > > > It doesn't work with more complex expressions (due to the nasty > > preprocessor pasting hack), and I couldn't figure out a way to make it > > do so. > > It's cute, but no, I also don't know how to make it work without the > preprocessor concatenation stuff. > > There is, however, an alternative that resembles the syntax in data > sheets even more closely: > > #define BITS(low_high) GENMASK((0 ? low_high), (1 ? low_high)) That is both beautiful and horrid... > > That'll work for > > unsigned long val1 = BITS(3:25); > unsigned long val3 = BITS(TESTVAL:31); > > for most of the things TESTVAL might expand to - I'm not sure what would > happen if one of the lo/hi values contains ternaries and isn't properly > parenthesized, but nobody writes stuff like > > #define RESET_BIT(rev) rev == 0xaa ? 7 : 9 > > It doesn't work for the single-bit case, but I don't think it's so bad > to have to say > > unsigned long val2 = BIT(4); > > and obviously BITS(4:4) would work as well. > > It also doesn't do anything to prevent the hi-lo 11:7 order. For constants that gets trapped. If the correct expression in used in GENMASK() the compiler will reject the negative shift - so doesn't need an explicit test. Not directly related... GENMASK() and the FIELD_GET() family need to go on massive diets. Nest them and the pre-processor generates multi-kb lines. Somewhere there is a (probably pointless) _Generic() for all the integer types. (Especially since FIELD_GET() is always u64.) FIELD_GET(mask, val) is just (val & mask) / (mask & -mask), but even that really needs mask assigned to a local (just to reduce the line length). For variable 'mask' you might worry about the cost of the 'divide by power of 2' but for constants it doesn't matter. FIELD_PREP(mask, val) is (val * (mask & -mask)) & mask 'Bloat city' comes from: #define MASK GENMASK(9, 0); x = FIELD_GET(MASK, MASK); I've just looked at bitfield.h - no wonder it bloats the world. 95% of it needs deleting :-) David > > Rasmus >