On Thu, Jan 18, 2024 at 02:42:12PM -0600, Lucas De Marchi wrote: > Hi, > > Reviving this thread as now with xe driver merged we have 2 users for > a fixed-width BIT/GENMASK. Can you point where and why? > On Wed, Jun 21, 2023 at 07:20:59PM -0700, Yury Norov wrote: > > Hi Lucas, all! > > > > (Thanks, Andy, for pointing to this thread.) > > > > On Mon, May 08, 2023 at 10:14:02PM -0700, Lucas De Marchi wrote: > > > Add GENMASK_U32(), GENMASK_U16() and GENMASK_U8() macros to create > > > masks for fixed-width types and also the corresponding BIT_U32(), > > > BIT_U16() and BIT_U8(). > > > > Can you split BIT() and GENMASK() material to separate patches? > > > > > All of those depend on a new "U" suffix added to the integer constant. > > > Due to naming clashes it's better to call the macro U32. Since C doesn't > > > have a proper suffix for short and char types, the U16 and U18 variants > > > just use U32 with one additional check in the BIT_* macros to make > > > sure the compiler gives an error when the those types overflow. > > > > I feel like I don't understand the sentence... > > > > > The BIT_U16() and BIT_U8() need the help of GENMASK_INPUT_CHECK(), > > > as otherwise they would allow an invalid bit to be passed. Hence > > > implement them in include/linux/bits.h rather than together with > > > the other BIT* variants. > > > > I don't think it's a good way to go because BIT() belongs to a more basic > > level than GENMASK(). Not mentioning possible header dependency issues. > > If you need to test against tighter numeric region, I'd suggest to > > do the same trick as GENMASK_INPUT_CHECK() does, but in uapi/linux/const.h > > directly. Something like: > > #define _U8(x) (CONST_GT(U8_MAX, x) + _AC(x, U)) > > but then make uapi/linux/const.h include linux/build_bug.h? > I was thinking about leaving BIT() define where it is, and add the > fixed-width versions in this header. I was thinking uapi/linux/const.h > was more about allowing the U/ULL suffixes for things shared with asm. You can't include kernel headers in uapi code. But you can try doing vice-versa: implement or move the pieces you need to share to the uapi/linux/const.h, and use them in the kernel code. In the worst case, you can just implement the macro you need in the uapi header, and make it working that way. Can you confirm that my proposal increases the kernel size? If so, is there any way to fix it? If it doesn't, I'd prefer to use the __GENMASK() approach. Thanks, Yury
