[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878r4dlosu.fsf@intel.com>
Date: Thu, 25 Jan 2024 11:56:01 +0200
From: Jani Nikula <jani.nikula@...el.com>
To: Gustavo Sousa <gustavo.sousa@...el.com>, Lucas De Marchi
<lucas.demarchi@...el.com>, Yury Norov <yury.norov@...il.com>
Cc: intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com>, intel-xe@...ts.freedesktop.org
Subject: Re: Re: [PATCH 1/3] bits: introduce fixed-type genmasks
On Wed, 24 Jan 2024, Gustavo Sousa <gustavo.sousa@...el.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@...el.com> wrote:
>>> > > From: Yury Norov <yury.norov@...il.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@...el.com>
--
Jani Nikula, Intel
Powered by blists - more mailing lists