[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z-LKapMBpMfJwcL7@thinkpad>
Date: Tue, 25 Mar 2025 11:23:22 -0400
From: Yury Norov <yury.norov@...il.com>
To: Vincent Mailhol <mailhol.vincent@...adoo.fr>
Cc: Lucas De Marchi <lucas.demarchi@...el.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Tvrtko Ursulin <tursulin@...ulin.net>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, intel-gfx@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org,
Andi Shyti <andi.shyti@...ux.intel.com>,
David Laight <David.Laight@...lab.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Jani Nikula <jani.nikula@...el.com>
Subject: Re: [PATCH v7 0/5] bits: Fixed-type GENMASK_U*() and BIT_U*()
On Tue, Mar 25, 2025 at 01:23:22AM +0900, Vincent Mailhol wrote:
> On 24/03/2025 at 23:28, Yury Norov wrote:
> > On Sat, Mar 22, 2025 at 06:23:11PM +0900, Vincent Mailhol via B4 Relay wrote:
> >> Introduce some fixed width variant of the GENMASK() and the BIT()
> >> macros in bits.h. Note that the main goal is not to get the correct
> >> type, but rather to enforce more checks at compile time. For example:
> >
> > You say this, and then typecast both BIT and GENMASK. This may confuse
> > readers. Maybe add few words about promotion rules in C standard, or
> > just drop this note entirely? Doesn't require new submission, of
> > course.
>
> I do not want to into this level of details in the cover letter, so I
> will remove. Instead, I can add below paragraph to the "bits: introduce
> fixed-type GENMASK_U*()" patch:
>
> The result is casted to the corresponding fixed width type. For
> example, GENMASK_U8() returns an u8. Note that because of the C
> promotion rules, GENMASK_U8() and GENMASK_U16() will immediately be
> promoted to int if used in an expression. Regardless, the main goal is
> not to get the correct type, but rather to enforce more checks at
> compile time.
>
> I staged this change in the v8 together with the other nitpicks from
> Andy. If you want that v8, let me know, it is ready. If you are happy
> enough with the v7 (and if it doesn't receive more comments), then go
> with it!
This series doesn't apply on 6.15-rc1 because test_bits.c has moved to
lib/tests. Can you please rebase your v8 and submit? I see no other
issues to merge it in bitmap-for-next.
Thanks,
Yury
Powered by blists - more mailing lists