From: Lucas De Marchi <lucas.demarchi@intel.com>

Implement fixed-type BIT_U*() to help drivers add stricter checks,
like it was done for GENMASK_U*().

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Co-developed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
---
Changelog:

  v5 -> v6:

    - No changes.

  v4 -> v5:

    - Rename GENMASK_t() to GENMASK_TYPE().

    - Use tab indentations instead of single space to separate the
      macro name from its body.

    - Add a global comment at the beginning of the file to explain why
      GENMASK_U*() and BIT_U*() are not available in asm.

    - Add a new BIT_TYPE() helper function, similar to GENMASK_TYPE().

    - Remove the unsigned int cast for the U8 and U16 variants. Move
      the cast to BIT_TYPE().

    - Rename the argument from BIT_U*(b) to BIT_U=(nr) for consistency
      with vdso/bits.h.

  v3 -> v4:

    - Use const_true() to simplify BIT_INPUT_CHECK().

    - Make BIT_U8() and BIT_U16() return an unsigned int instead of a
      u8 and u16. Because of the integer promotion rules in C, an u8
      or an u16 would become a signed integer as soon as these are
      used in any expression. By casting these to unsigned ints, at
      least the signedness is kept.

    - Put the cast next to the BIT() macro.

    - In BIT_U64(): use BIT_ULL() instead of BIT().
---
 include/linux/bits.h | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/include/linux/bits.h b/include/linux/bits.h
index b690611c769be61ab2b5ced43c8302ba5693308b..b234ef0394f133c8f11388fb6a4a5448d8ba9994 100644
--- a/include/linux/bits.h
+++ b/include/linux/bits.h
@@ -22,10 +22,10 @@
 /*
  * Missing asm support
  *
- * GENMASK_U*() depends on BITS_PER_TYPE() which relies on sizeof(),
- * something not available in asm. Nethertheless, fixed width integers
- * is a C concept. Assembly code can rely on the long and long long
- * versions instead.
+ * GENMASK_U*() and BIT_U*() depend on BITS_PER_TYPE() which relies on
+ * sizeof(), something not available in asm. Nethertheless, fixed
+ * width integers is a C concept. Assembly code can rely on the long
+ * and long long versions instead.
  */
 
 #include <linux/build_bug.h>
@@ -58,6 +58,24 @@
 #define GENMASK_U64(h, l)	GENMASK_TYPE(u64, h, l)
 #define GENMASK_U128(h, l)	GENMASK_TYPE(u128, h, l)
 
+/*
+ * Fixed-type variants of BIT(), with additional checks like GENMASK_TYPE(). The
+ * following examples generate compiler warnings due to shift-count-overflow:
+ *
+ * - BIT_U8(8)
+ * - BIT_U32(-1)
+ * - BIT_U32(40)
+ */
+#define BIT_INPUT_CHECK(type, nr) \
+	BUILD_BUG_ON_ZERO(const_true((nr) >= BITS_PER_TYPE(type)))
+
+#define BIT_TYPE(type, nr) ((type)(BIT_INPUT_CHECK(type, nr) + BIT_ULL(nr)))
+
+#define BIT_U8(nr)	BIT_TYPE(u8, nr)
+#define BIT_U16(nr)	BIT_TYPE(u16, nr)
+#define BIT_U32(nr)	BIT_TYPE(u32, nr)
+#define BIT_U64(nr)	BIT_TYPE(u64, nr)
+
 #else /* defined(__ASSEMBLY__) */
 
 /*

-- 
2.45.3

On Sat, Mar 08, 2025 at 01:48:50AM +0900, Vincent Mailhol via B4 Relay wrote:
> From: Lucas De Marchi <lucas.demarchi@intel.com>
> 
> Implement fixed-type BIT_U*() to help drivers add stricter checks,
> like it was done for GENMASK_U*().

...

>  /*
>   * Missing asm support
>   *
> - * GENMASK_U*() depends on BITS_PER_TYPE() which relies on sizeof(),
> - * something not available in asm. Nethertheless, fixed width integers
> - * is a C concept. Assembly code can rely on the long and long long
> - * versions instead.
> + * GENMASK_U*() and BIT_U*() depend on BITS_PER_TYPE() which relies on
> + * sizeof(), something not available in asm. Nethertheless, fixed
> + * width integers is a C concept. Assembly code can rely on the long
> + * and long long versions instead.
>   */

I don't like this hunk. You just introduced a message which is rewritten
completely in the immediate followup. Can you come up in a better text
here and/or there so it will give only + LoCs (or minimizes - to 1:ish)?

-- 
With Best Regards,
Andy Shevchenko

On Fri, Mar 07, 2025 at 07:48:01PM +0200, Andy Shevchenko wrote:
> On Sat, Mar 08, 2025 at 01:48:50AM +0900, Vincent Mailhol via B4 Relay wrote:

...

> >  /*
> >   * Missing asm support
> >   *
> > - * GENMASK_U*() depends on BITS_PER_TYPE() which relies on sizeof(),
> > - * something not available in asm. Nethertheless, fixed width integers
> > - * is a C concept. Assembly code can rely on the long and long long
> > - * versions instead.
> > + * GENMASK_U*() and BIT_U*() depend on BITS_PER_TYPE() which relies on
> > + * sizeof(), something not available in asm. Nethertheless, fixed
> > + * width integers is a C concept. Assembly code can rely on the long
> > + * and long long versions instead.
> >   */
> 
> I don't like this hunk. You just introduced a message which is rewritten
> completely in the immediate followup. Can you come up in a better text
> here and/or there so it will give only + LoCs (or minimizes - to 1:ish)?

And also note, that using up to 90 characters in the comments most likely fine
here. At least I don't see a problem with that.

-- 
With Best Regards,
Andy Shevchenko

On 08/03/2025 at 02:49, Andy Shevchenko wrote:
> On Fri, Mar 07, 2025 at 07:48:01PM +0200, Andy Shevchenko wrote:
>> On Sat, Mar 08, 2025 at 01:48:50AM +0900, Vincent Mailhol via B4 Relay wrote:
> 
> ...
> 
>>>  /*
>>>   * Missing asm support
>>>   *
>>> - * GENMASK_U*() depends on BITS_PER_TYPE() which relies on sizeof(),
>>> - * something not available in asm. Nethertheless, fixed width integers
>>> - * is a C concept. Assembly code can rely on the long and long long
>>> - * versions instead.
>>> + * GENMASK_U*() and BIT_U*() depend on BITS_PER_TYPE() which relies on
>>> + * sizeof(), something not available in asm. Nethertheless, fixed
>>> + * width integers is a C concept. Assembly code can rely on the long
>>> + * and long long versions instead.
>>>   */
>>
>> I don't like this hunk. You just introduced a message which is rewritten
>> completely in the immediate followup. Can you come up in a better text
>> here and/or there so it will give only + LoCs (or minimizes - to 1:ish)?

OK. I will add an artificial early new line in the previous patch so
that the diff is only one line.

> And also note, that using up to 90 characters in the comments most likely fine
> here. At least I don't see a problem with that.

I re-wrapped the text to the 80 column and it now fits on three lines.
90 column wouldn't reduce the line count, so I am keeping it to 80.


Yours sincerely,
Vincent Mailhol