[Intel-gfx] [PATCH v5 1/7] drm: Move and add a few utility macros into drm util header

Andi Shyti andi.shyti at linux.intel.com
Thu Aug 4 09:06:52 UTC 2022


Hi Jani,

> >> It moves overflows_type utility macro into drm util header from i915_utils
> >> header. The overflows_type can be used to catch the truncation between data
> >> types. And it adds safe_conversion() macro which performs a type conversion
> >> (cast) of an source value into a new variable, checking that the
> >> destination is large enough to hold the source value.
> >> And it adds exact_type and exactly_pgoff_t macro to catch type mis-match
> >> while compiling.
> >> 
> >> v3: Add is_type_unsigned() macro (Mauro)
> >>     Modify overflows_type() macro to consider signed data types (Mauro)
> >>     Fix the problem that safe_conversion() macro always returns true
> >> v4: Fix kernel-doc markups
> >> 
> >> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun at intel.com>
> >> Cc: Thomas Hellström <thomas.hellstrom at linux.intel.com>
> >> Cc: Matthew Auld <matthew.auld at intel.com>
> >> Cc: Nirmoy Das <nirmoy.das at intel.com>
> >> Cc: Jani Nikula <jani.nikula at intel.com>
> >> Reviewed-by: Mauro Carvalho Chehab <mchehab at kernel.org>
> >> ---
> >>  drivers/gpu/drm/i915/i915_utils.h |  5 +-
> >>  include/drm/drm_util.h            | 77 +++++++++++++++++++++++++++++++
> >>  2 files changed, 78 insertions(+), 4 deletions(-)
> >
> > Jani and Mauro suggested to have this macro in
> > include/drm/drm_util.h.
> 
> I can't recall suggesting such a thing. The macros in question have
> nothing specifically to do with i915 *or* drm. They are generic, and
> should be in generic kernel headers.
> 
> We must stop piling up generic and generally useful stuff in our own
> headers.

Yes, I agree with you and I think there was already such
discussion whether to move this into generic kernel headers or in
drm header.

Gwan-gyeong, any thoughts or further plans to move this to a
different place? It's been already three people (and I'm
including myself here) recommending to have this in a different
place.

Andi

> I thought I've been clear about this all along.

Thanks, Jani!

Andi


More information about the dri-devel mailing list