linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Gustavo Sousa <gustavo.sousa@intel.com>,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	Yury Norov <yury.norov@gmail.com>
Cc: intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	intel-xe@lists.freedesktop.org
Subject: Re: Re: [PATCH 1/3] bits: introduce fixed-type genmasks
Date: Thu, 25 Jan 2024 11:56:01 +0200	[thread overview]
Message-ID: <878r4dlosu.fsf@intel.com> (raw)
In-Reply-To: <170611134445.31262.2799581830173501277@gjsousa-mobl2>

On Wed, 24 Jan 2024, Gustavo Sousa <gustavo.sousa@intel.com> wrote:
> Quoting Yury Norov (2024-01-24 12:27:58-03:00)
>>On Wed, Jan 24, 2024 at 08:03:53AM -0600, Lucas De Marchi wrote:
>>> On Wed, Jan 24, 2024 at 09:58:26AM +0200, Jani Nikula wrote:
>>> > On Tue, 23 Jan 2024, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
>>> > > From: Yury Norov <yury.norov@gmail.com>
>>> > > 
>>> > > Generalize __GENMASK() to support different types, and implement
>>> > > fixed-types versions of GENMASK() based on it. The fixed-type version
>>> > > allows more strict checks to the min/max values accepted, which is
>>> > > useful for defining registers like implemented by i915 and xe drivers
>>> > > with their REG_GENMASK*() macros.
>>> > 
>>> > Mmh, the commit message says the fixed-type version allows more strict
>>> > checks, but none are actually added. GENMASK_INPUT_CHECK() remains the
>>> > same.
>>> > 
>>> > Compared to the i915 and xe versions, this is more lax now. You could
>>> > specify GENMASK_U32(63,32) without complaints.
>>> 
>>> Doing this on top of the this series:
>>> 
>>> -#define   XELPDP_PORT_M2P_COMMAND_TYPE_MASK            REG_GENMASK(30, 27)
>>> +#define   XELPDP_PORT_M2P_COMMAND_TYPE_MASK            REG_GENMASK(62, 32)
>>> 
>>> and I do get a build failure:
>>> 
>>> ../drivers/gpu/drm/i915/display/intel_cx0_phy.c: In function ‘__intel_cx0_read_once’:
>>> ../include/linux/bits.h:41:31: error: left shift count >= width of type [-Werror=shift-count-overflow]
>>>    41 |          (((t)~0ULL - ((t)(1) << (l)) + 1) & \
>>>       |                               ^~

I stand corrected.

>>
>>I would better include this in commit message to avoid people's
>>confusion. If it comes to v2, can you please do it and mention that
>>this trick relies on shift-count-overflow compiler check?
>
> Wouldn't it be better to have explicit check that l and h are not out of bounds
> based on BITS_PER_TYPE() than relying on a compiler flag that could be turned
> off (maybe for some questionable reason, but even so)?

My preference would be the explicit check, a comment in code, or an
explanation in the commit message, in this order. Because honestly, none
of this is obvious, and a future refactoring of GENMASK might just
inadvertently thwart the whole check.

Regardless, my main concern was moot, on the series,

Acked-by: Jani Nikula <jani.nikula@intel.com>


-- 
Jani Nikula, Intel

  reply	other threads:[~2024-01-25  9:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-24  5:02 [PATCH 0/3] Fixed-type GENMASK/BIT Lucas De Marchi
2024-01-24  5:02 ` [PATCH 1/3] bits: introduce fixed-type genmasks Lucas De Marchi
2024-01-24  7:58   ` Jani Nikula
2024-01-24 14:03     ` Lucas De Marchi
2024-01-24 15:27       ` Yury Norov
2024-01-24 15:49         ` Gustavo Sousa
2024-01-25  9:56           ` Jani Nikula [this message]
2024-01-29 14:49         ` Lucas De Marchi
2024-01-29 15:11           ` Yury Norov
2024-01-24  5:02 ` [PATCH 2/3] bits: Introduce fixed-type BIT Lucas De Marchi
2024-02-09 16:48   ` Yury Norov
2024-01-24  5:02 ` [PATCH 3/3] drm/i915: Convert REG_GENMASK* to fixed-width GENMASK_* Lucas De Marchi
2024-01-24  8:04   ` Jani Nikula

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=878r4dlosu.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo.sousa@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).