From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Cc: Yury Norov <yury.norov@gmail.com>,
Lucas De Marchi <lucas.demarchi@intel.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Tvrtko Ursulin <tursulin@ursulin.net>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org,
Andi Shyti <andi.shyti@linux.intel.com>,
David Laight <David.Laight@aculab.com>,
Jani Nikula <jani.nikula@intel.com>
Subject: Re: [PATCH v7 2/5] bits: introduce fixed-type BIT_U*()
Date: Mon, 24 Mar 2025 16:32:50 +0200 [thread overview]
Message-ID: <Z-FtEr31u0jmeSRX@smile.fi.intel.com> (raw)
In-Reply-To: <b7718c92-3934-4ce7-b9a1-0d8ac03dadc3@wanadoo.fr>
On Mon, Mar 24, 2025 at 11:16:30PM +0900, Vincent Mailhol wrote:
> On 24/03/2025 at 22:41, Andy Shevchenko wrote:
> > On Sat, Mar 22, 2025 at 06:23:13PM +0900, Vincent Mailhol via B4 Relay wrote:
...
> >> +/*
> >> + * Fixed-type variants of BIT(), with additional checks like GENMASK_TYPE(). The
> >> + * following examples generate compiler warnings due to shift-count-overflow:
> >
> > "...due to -Wshift-count-overflow:" ?
> >
> > Same idea — if you need a new version, since it's just a nit-pick.
>
> If you want. I staged this change locally, so if there is a v8, it will
> be addressed. I applied the same to the previous patch which also
> mentioned shift-count-overflow without the -W prefix.
>
> But honestly, I am not convinced of the added value. This is from Lucas
> original patch one year ago, and no one was bothered by this. IMHO, when
> writing:
>
> (...) generate compiler warnings due to shift-count-overflow:
>
> I do not see where the ambiguity is. The sentence clearly say that this
> is a compiler warning, so with or without the -W prefix, the sentence is
> equally understandable.
As I marked, it's a nit-pick, but from my point of view the added value
is immediate: The reader can be sure that we are talking about a compiler
warning and not something else (C standard? some special term?). So it adds
more context and makes it clearer.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-03-24 14:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-22 9:23 [PATCH v7 0/5] bits: Fixed-type GENMASK_U*() and BIT_U*() Vincent Mailhol
2025-03-22 9:23 ` Vincent Mailhol via B4 Relay
2025-03-22 9:23 ` [PATCH v7 1/5] bits: introduce fixed-type GENMASK_U*() Vincent Mailhol
2025-03-22 9:23 ` Vincent Mailhol via B4 Relay
2025-03-24 7:22 ` Andy Shevchenko
2025-03-24 7:44 ` Vincent Mailhol
2025-03-22 9:23 ` [PATCH v7 2/5] bits: introduce fixed-type BIT_U*() Vincent Mailhol
2025-03-22 9:23 ` Vincent Mailhol via B4 Relay
2025-03-24 13:41 ` Andy Shevchenko
2025-03-24 14:16 ` Vincent Mailhol
2025-03-24 14:32 ` Andy Shevchenko [this message]
2025-03-22 9:23 ` [PATCH v7 3/5] drm/i915: Convert REG_GENMASK*() to fixed-width GENMASK_U*() Vincent Mailhol
2025-03-22 9:23 ` Vincent Mailhol via B4 Relay
2025-03-22 9:23 ` [PATCH v7 4/5] test_bits: add tests for GENMASK_U*() Vincent Mailhol
2025-03-22 9:23 ` Vincent Mailhol via B4 Relay
2025-03-22 9:23 ` [PATCH v7 5/5] test_bits: add tests for BIT_U*() Vincent Mailhol
2025-03-22 9:23 ` Vincent Mailhol via B4 Relay
2025-03-22 10:07 ` ✗ Fi.CI.CHECKPATCH: warning for bits: Fixed-type GENMASK_U*() and BIT_U*() (rev2) Patchwork
2025-03-22 10:07 ` ✗ Fi.CI.SPARSE: " Patchwork
2025-03-22 16:19 ` ✓ i915.CI.BAT: success " Patchwork
2025-03-22 17:51 ` ✗ i915.CI.Full: failure " Patchwork
2025-03-24 14:28 ` [PATCH v7 0/5] bits: Fixed-type GENMASK_U*() and BIT_U*() Yury Norov
2025-03-24 16:23 ` Vincent Mailhol
2025-03-25 15:23 ` Yury Norov
2025-03-25 16:13 ` Vincent Mailhol
2025-03-25 16:30 ` Yury Norov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z-FtEr31u0jmeSRX@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=David.Laight@aculab.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andi.shyti@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=lucas.demarchi@intel.com \
--cc=mailhol.vincent@wanadoo.fr \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
--cc=tursulin@ursulin.net \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.