| Message ID | 20181114120806.694-1-lionel.g.landwerlin@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/i915: use appropriate integer types for flags | expand |
Quoting Lionel Landwerlin (2018-11-14 12:08:06) > We've been dealing a number of 32/64 bits flags issues lately : > > - 085603287452fc ("drm/i915: Compare user's 64b GTT offset even on 32b") > - c58281056a8b26 ("drm/i915: Mark up GTT sizes as u64") > - 83b466b1dc5f0b ("drm/i915: Mark pin flags as u64") > > As userspace and in particular Mesa pulls in the uAPI headers and > builds up flags using the uAPI defines we should probably make those > more explicitly 32/64bits aware. I just want to note that since these happen to be signed values, we don't have the same issue with zero-extension of their inverses. I don't think there's user impact here; no requirement for cc:stable. > Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> > --- > include/uapi/drm/i915_drm.h | 90 ++++++++++++++++++------------------- > 1 file changed, 45 insertions(+), 45 deletions(-) > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > index e477ef8c644e..f562c4239bd8 100644 > --- a/include/uapi/drm/i915_drm.h > +++ b/include/uapi/drm/i915_drm.h > @@ -895,12 +895,12 @@ struct drm_i915_gem_exec_object2 { > */ > __u64 offset; > > -#define EXEC_OBJECT_NEEDS_FENCE (1<<0) > -#define EXEC_OBJECT_NEEDS_GTT (1<<1) > -#define EXEC_OBJECT_WRITE (1<<2) > -#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3) > -#define EXEC_OBJECT_PINNED (1<<4) > -#define EXEC_OBJECT_PAD_TO_SIZE (1<<5) > +#define EXEC_OBJECT_NEEDS_FENCE (1ULL<<0) We should probably appease CODING_STYLE a bit more while we are here; (1ULL << 0) -Chris
On Wed, Nov 14, 2018 at 12:08:06PM +0000, Lionel Landwerlin wrote: > We've been dealing a number of 32/64 bits flags issues lately : > > - 085603287452fc ("drm/i915: Compare user's 64b GTT offset even on 32b") > - c58281056a8b26 ("drm/i915: Mark up GTT sizes as u64") > - 83b466b1dc5f0b ("drm/i915: Mark pin flags as u64") > > As userspace and in particular Mesa pulls in the uAPI headers and > builds up flags using the uAPI defines we should probably make those > more explicitly 32/64bits aware. > > Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> > --- > include/uapi/drm/i915_drm.h | 90 ++++++++++++++++++------------------- > 1 file changed, 45 insertions(+), 45 deletions(-) > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > index e477ef8c644e..f562c4239bd8 100644 > --- a/include/uapi/drm/i915_drm.h > +++ b/include/uapi/drm/i915_drm.h > @@ -895,12 +895,12 @@ struct drm_i915_gem_exec_object2 { > */ > __u64 offset; > > -#define EXEC_OBJECT_NEEDS_FENCE (1<<0) > -#define EXEC_OBJECT_NEEDS_GTT (1<<1) > -#define EXEC_OBJECT_WRITE (1<<2) > -#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3) > -#define EXEC_OBJECT_PINNED (1<<4) > -#define EXEC_OBJECT_PAD_TO_SIZE (1<<5) > +#define EXEC_OBJECT_NEEDS_FENCE (1ULL<<0) > +#define EXEC_OBJECT_NEEDS_GTT (1ULL<<1) > +#define EXEC_OBJECT_WRITE (1ULL<<2) > +#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1ULL<<3) > +#define EXEC_OBJECT_PINNED (1ULL<<4) > +#define EXEC_OBJECT_PAD_TO_SIZE (1ULL<<5) > /* The kernel implicitly tracks GPU activity on all GEM objects, and > * synchronises operations with outstanding rendering. This includes > * rendering on other devices if exported via dma-buf. However, sometimes > @@ -921,14 +921,14 @@ struct drm_i915_gem_exec_object2 { > * explicit tracking to avoid rendering corruption. See, for example, > * I915_PARAM_HAS_EXEC_FENCE to order execbufs and execute them asynchronously. > */ > -#define EXEC_OBJECT_ASYNC (1<<6) > +#define EXEC_OBJECT_ASYNC (1ULL<<6) > /* Request that the contents of this execobject be copied into the error > * state upon a GPU hang involving this batch for post-mortem debugging. > * These buffers are recorded in no particular order as "user" in > * /sys/class/drm/cardN/error. Query I915_PARAM_HAS_EXEC_CAPTURE to see > * if the kernel supports this flag. > */ > -#define EXEC_OBJECT_CAPTURE (1<<7) > +#define EXEC_OBJECT_CAPTURE (1ULL<<7) > /* All remaining bits are MBZ and RESERVED FOR FUTURE USE */ > #define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_CAPTURE<<1) > __u64 flags; > @@ -946,8 +946,8 @@ struct drm_i915_gem_exec_fence { > */ > __u32 handle; > > -#define I915_EXEC_FENCE_WAIT (1<<0) > -#define I915_EXEC_FENCE_SIGNAL (1<<1) > +#define I915_EXEC_FENCE_WAIT (1UL<<0) > +#define I915_EXEC_FENCE_SIGNAL (1UL<<1) UL doesn't make much sense to me. It can be 32 or 64 bits depending on the architecture.
On 14/11/2018 13:22, Ville Syrjälä wrote: > On Wed, Nov 14, 2018 at 12:08:06PM +0000, Lionel Landwerlin wrote: >> We've been dealing a number of 32/64 bits flags issues lately : >> >> - 085603287452fc ("drm/i915: Compare user's 64b GTT offset even on 32b") >> - c58281056a8b26 ("drm/i915: Mark up GTT sizes as u64") >> - 83b466b1dc5f0b ("drm/i915: Mark pin flags as u64") >> >> As userspace and in particular Mesa pulls in the uAPI headers and >> builds up flags using the uAPI defines we should probably make those >> more explicitly 32/64bits aware. >> >> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> >> --- >> include/uapi/drm/i915_drm.h | 90 ++++++++++++++++++------------------- >> 1 file changed, 45 insertions(+), 45 deletions(-) >> >> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h >> index e477ef8c644e..f562c4239bd8 100644 >> --- a/include/uapi/drm/i915_drm.h >> +++ b/include/uapi/drm/i915_drm.h >> @@ -895,12 +895,12 @@ struct drm_i915_gem_exec_object2 { >> */ >> __u64 offset; >> >> -#define EXEC_OBJECT_NEEDS_FENCE (1<<0) >> -#define EXEC_OBJECT_NEEDS_GTT (1<<1) >> -#define EXEC_OBJECT_WRITE (1<<2) >> -#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3) >> -#define EXEC_OBJECT_PINNED (1<<4) >> -#define EXEC_OBJECT_PAD_TO_SIZE (1<<5) >> +#define EXEC_OBJECT_NEEDS_FENCE (1ULL<<0) >> +#define EXEC_OBJECT_NEEDS_GTT (1ULL<<1) >> +#define EXEC_OBJECT_WRITE (1ULL<<2) >> +#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1ULL<<3) >> +#define EXEC_OBJECT_PINNED (1ULL<<4) >> +#define EXEC_OBJECT_PAD_TO_SIZE (1ULL<<5) >> /* The kernel implicitly tracks GPU activity on all GEM objects, and >> * synchronises operations with outstanding rendering. This includes >> * rendering on other devices if exported via dma-buf. However, sometimes >> @@ -921,14 +921,14 @@ struct drm_i915_gem_exec_object2 { >> * explicit tracking to avoid rendering corruption. See, for example, >> * I915_PARAM_HAS_EXEC_FENCE to order execbufs and execute them asynchronously. >> */ >> -#define EXEC_OBJECT_ASYNC (1<<6) >> +#define EXEC_OBJECT_ASYNC (1ULL<<6) >> /* Request that the contents of this execobject be copied into the error >> * state upon a GPU hang involving this batch for post-mortem debugging. >> * These buffers are recorded in no particular order as "user" in >> * /sys/class/drm/cardN/error. Query I915_PARAM_HAS_EXEC_CAPTURE to see >> * if the kernel supports this flag. >> */ >> -#define EXEC_OBJECT_CAPTURE (1<<7) >> +#define EXEC_OBJECT_CAPTURE (1ULL<<7) >> /* All remaining bits are MBZ and RESERVED FOR FUTURE USE */ >> #define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_CAPTURE<<1) >> __u64 flags; >> @@ -946,8 +946,8 @@ struct drm_i915_gem_exec_fence { >> */ >> __u32 handle; >> >> -#define I915_EXEC_FENCE_WAIT (1<<0) >> -#define I915_EXEC_FENCE_SIGNAL (1<<1) >> +#define I915_EXEC_FENCE_WAIT (1UL<<0) >> +#define I915_EXEC_FENCE_SIGNAL (1UL<<1) > UL doesn't make much sense to me. It can be 32 or 64 bits depending on > the architecture. > Are you suggesting ULL instead?
On Fri, Nov 16, 2018 at 10:43:39AM +0000, Lionel Landwerlin wrote: > On 14/11/2018 13:22, Ville Syrjälä wrote: > > On Wed, Nov 14, 2018 at 12:08:06PM +0000, Lionel Landwerlin wrote: > >> We've been dealing a number of 32/64 bits flags issues lately : > >> > >> - 085603287452fc ("drm/i915: Compare user's 64b GTT offset even on 32b") > >> - c58281056a8b26 ("drm/i915: Mark up GTT sizes as u64") > >> - 83b466b1dc5f0b ("drm/i915: Mark pin flags as u64") > >> > >> As userspace and in particular Mesa pulls in the uAPI headers and > >> builds up flags using the uAPI defines we should probably make those > >> more explicitly 32/64bits aware. > >> > >> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> > >> --- > >> include/uapi/drm/i915_drm.h | 90 ++++++++++++++++++------------------- > >> 1 file changed, 45 insertions(+), 45 deletions(-) > >> > >> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > >> index e477ef8c644e..f562c4239bd8 100644 > >> --- a/include/uapi/drm/i915_drm.h > >> +++ b/include/uapi/drm/i915_drm.h > >> @@ -895,12 +895,12 @@ struct drm_i915_gem_exec_object2 { > >> */ > >> __u64 offset; > >> > >> -#define EXEC_OBJECT_NEEDS_FENCE (1<<0) > >> -#define EXEC_OBJECT_NEEDS_GTT (1<<1) > >> -#define EXEC_OBJECT_WRITE (1<<2) > >> -#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3) > >> -#define EXEC_OBJECT_PINNED (1<<4) > >> -#define EXEC_OBJECT_PAD_TO_SIZE (1<<5) > >> +#define EXEC_OBJECT_NEEDS_FENCE (1ULL<<0) > >> +#define EXEC_OBJECT_NEEDS_GTT (1ULL<<1) > >> +#define EXEC_OBJECT_WRITE (1ULL<<2) > >> +#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1ULL<<3) > >> +#define EXEC_OBJECT_PINNED (1ULL<<4) > >> +#define EXEC_OBJECT_PAD_TO_SIZE (1ULL<<5) > >> /* The kernel implicitly tracks GPU activity on all GEM objects, and > >> * synchronises operations with outstanding rendering. This includes > >> * rendering on other devices if exported via dma-buf. However, sometimes > >> @@ -921,14 +921,14 @@ struct drm_i915_gem_exec_object2 { > >> * explicit tracking to avoid rendering corruption. See, for example, > >> * I915_PARAM_HAS_EXEC_FENCE to order execbufs and execute them asynchronously. > >> */ > >> -#define EXEC_OBJECT_ASYNC (1<<6) > >> +#define EXEC_OBJECT_ASYNC (1ULL<<6) > >> /* Request that the contents of this execobject be copied into the error > >> * state upon a GPU hang involving this batch for post-mortem debugging. > >> * These buffers are recorded in no particular order as "user" in > >> * /sys/class/drm/cardN/error. Query I915_PARAM_HAS_EXEC_CAPTURE to see > >> * if the kernel supports this flag. > >> */ > >> -#define EXEC_OBJECT_CAPTURE (1<<7) > >> +#define EXEC_OBJECT_CAPTURE (1ULL<<7) > >> /* All remaining bits are MBZ and RESERVED FOR FUTURE USE */ > >> #define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_CAPTURE<<1) > >> __u64 flags; > >> @@ -946,8 +946,8 @@ struct drm_i915_gem_exec_fence { > >> */ > >> __u32 handle; > >> > >> -#define I915_EXEC_FENCE_WAIT (1<<0) > >> -#define I915_EXEC_FENCE_SIGNAL (1<<1) > >> +#define I915_EXEC_FENCE_WAIT (1UL<<0) > >> +#define I915_EXEC_FENCE_SIGNAL (1UL<<1) > > UL doesn't make much sense to me. It can be 32 or 64 bits depending on > > the architecture. > > > Are you suggesting ULL instead? What's wrong with a plain u?
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h index e477ef8c644e..f562c4239bd8 100644 --- a/include/uapi/drm/i915_drm.h +++ b/include/uapi/drm/i915_drm.h @@ -895,12 +895,12 @@ struct drm_i915_gem_exec_object2 { */ __u64 offset; -#define EXEC_OBJECT_NEEDS_FENCE (1<<0) -#define EXEC_OBJECT_NEEDS_GTT (1<<1) -#define EXEC_OBJECT_WRITE (1<<2) -#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3) -#define EXEC_OBJECT_PINNED (1<<4) -#define EXEC_OBJECT_PAD_TO_SIZE (1<<5) +#define EXEC_OBJECT_NEEDS_FENCE (1ULL<<0) +#define EXEC_OBJECT_NEEDS_GTT (1ULL<<1) +#define EXEC_OBJECT_WRITE (1ULL<<2) +#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1ULL<<3) +#define EXEC_OBJECT_PINNED (1ULL<<4) +#define EXEC_OBJECT_PAD_TO_SIZE (1ULL<<5) /* The kernel implicitly tracks GPU activity on all GEM objects, and * synchronises operations with outstanding rendering. This includes * rendering on other devices if exported via dma-buf. However, sometimes @@ -921,14 +921,14 @@ struct drm_i915_gem_exec_object2 { * explicit tracking to avoid rendering corruption. See, for example, * I915_PARAM_HAS_EXEC_FENCE to order execbufs and execute them asynchronously. */ -#define EXEC_OBJECT_ASYNC (1<<6) +#define EXEC_OBJECT_ASYNC (1ULL<<6) /* Request that the contents of this execobject be copied into the error * state upon a GPU hang involving this batch for post-mortem debugging. * These buffers are recorded in no particular order as "user" in * /sys/class/drm/cardN/error. Query I915_PARAM_HAS_EXEC_CAPTURE to see * if the kernel supports this flag. */ -#define EXEC_OBJECT_CAPTURE (1<<7) +#define EXEC_OBJECT_CAPTURE (1ULL<<7) /* All remaining bits are MBZ and RESERVED FOR FUTURE USE */ #define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_CAPTURE<<1) __u64 flags; @@ -946,8 +946,8 @@ struct drm_i915_gem_exec_fence { */ __u32 handle; -#define I915_EXEC_FENCE_WAIT (1<<0) -#define I915_EXEC_FENCE_SIGNAL (1<<1) +#define I915_EXEC_FENCE_WAIT (1UL<<0) +#define I915_EXEC_FENCE_SIGNAL (1UL<<1) #define __I915_EXEC_FENCE_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_SIGNAL << 1)) __u32 flags; }; @@ -972,12 +972,12 @@ struct drm_i915_gem_execbuffer2 { * struct drm_i915_gem_exec_fence *fences. */ __u64 cliprects_ptr; -#define I915_EXEC_RING_MASK (7<<0) -#define I915_EXEC_DEFAULT (0<<0) -#define I915_EXEC_RENDER (1<<0) -#define I915_EXEC_BSD (2<<0) -#define I915_EXEC_BLT (3<<0) -#define I915_EXEC_VEBOX (4<<0) +#define I915_EXEC_RING_MASK (7ULL<<0) +#define I915_EXEC_DEFAULT (0ULL<<0) +#define I915_EXEC_RENDER (1ULL<<0) +#define I915_EXEC_BSD (2ULL<<0) +#define I915_EXEC_BLT (3ULL<<0) +#define I915_EXEC_VEBOX (4ULL<<0) /* Used for switching the constants addressing mode on gen4+ RENDER ring. * Gen6+ only supports relative addressing to dynamic state (default) and @@ -985,22 +985,22 @@ struct drm_i915_gem_execbuffer2 { * * These flags are ignored for the BSD and BLT rings. */ -#define I915_EXEC_CONSTANTS_MASK (3<<6) -#define I915_EXEC_CONSTANTS_REL_GENERAL (0<<6) /* default */ -#define I915_EXEC_CONSTANTS_ABSOLUTE (1<<6) -#define I915_EXEC_CONSTANTS_REL_SURFACE (2<<6) /* gen4/5 only */ +#define I915_EXEC_CONSTANTS_MASK (3ULL<<6) +#define I915_EXEC_CONSTANTS_REL_GENERAL (0ULL<<6) /* default */ +#define I915_EXEC_CONSTANTS_ABSOLUTE (1ULL<<6) +#define I915_EXEC_CONSTANTS_REL_SURFACE (2ULL<<6) /* gen4/5 only */ __u64 flags; __u64 rsvd1; /* now used for context info */ __u64 rsvd2; }; /** Resets the SO write offset registers for transform feedback on gen7. */ -#define I915_EXEC_GEN7_SOL_RESET (1<<8) +#define I915_EXEC_GEN7_SOL_RESET (1ULL<<8) /** Request a privileged ("secure") batch buffer. Note only available for * DRM_ROOT_ONLY | DRM_MASTER processes. */ -#define I915_EXEC_SECURE (1<<9) +#define I915_EXEC_SECURE (1ULL<<9) /** Inform the kernel that the batch is and will always be pinned. This * negates the requirement for a workaround to be performed to avoid @@ -1009,32 +1009,32 @@ struct drm_i915_gem_execbuffer2 { * coherent with the CS before execution. If this flag is passed, * userspace assumes the responsibility for ensuring the same. */ -#define I915_EXEC_IS_PINNED (1<<10) +#define I915_EXEC_IS_PINNED (1ULL<<10) /** Provide a hint to the kernel that the command stream and auxiliary * state buffers already holds the correct presumed addresses and so the * relocation process may be skipped if no buffers need to be moved in * preparation for the execbuffer. */ -#define I915_EXEC_NO_RELOC (1<<11) +#define I915_EXEC_NO_RELOC (1ULL<<11) /** Use the reloc.handle as an index into the exec object array rather * than as the per-file handle. */ -#define I915_EXEC_HANDLE_LUT (1<<12) +#define I915_EXEC_HANDLE_LUT (1ULL<<12) /** Used for switching BSD rings on the platforms with two BSD rings */ #define I915_EXEC_BSD_SHIFT (13) -#define I915_EXEC_BSD_MASK (3 << I915_EXEC_BSD_SHIFT) +#define I915_EXEC_BSD_MASK (3ULL << I915_EXEC_BSD_SHIFT) /* default ping-pong mode */ -#define I915_EXEC_BSD_DEFAULT (0 << I915_EXEC_BSD_SHIFT) -#define I915_EXEC_BSD_RING1 (1 << I915_EXEC_BSD_SHIFT) -#define I915_EXEC_BSD_RING2 (2 << I915_EXEC_BSD_SHIFT) +#define I915_EXEC_BSD_DEFAULT (0ULL << I915_EXEC_BSD_SHIFT) +#define I915_EXEC_BSD_RING1 (1ULL << I915_EXEC_BSD_SHIFT) +#define I915_EXEC_BSD_RING2 (2ULL << I915_EXEC_BSD_SHIFT) /** Tell the kernel that the batchbuffer is processed by * the resource streamer. */ -#define I915_EXEC_RESOURCE_STREAMER (1<<15) +#define I915_EXEC_RESOURCE_STREAMER (1ULL<<15) /* Setting I915_EXEC_FENCE_IN implies that lower_32_bits(rsvd2) represent * a sync_file fd to wait upon (in a nonblocking manner) prior to executing @@ -1042,7 +1042,7 @@ struct drm_i915_gem_execbuffer2 { * * Returns -EINVAL if the sync_file fd cannot be found. */ -#define I915_EXEC_FENCE_IN (1<<16) +#define I915_EXEC_FENCE_IN (1ULL<<16) /* Setting I915_EXEC_FENCE_OUT causes the ioctl to return a sync_file fd * in the upper_32_bits(rsvd2) upon success. Ownership of the fd is given @@ -1059,7 +1059,7 @@ struct drm_i915_gem_execbuffer2 { * back to userspace. Failure to do so will cause the out-fence to always * be reported as zero, and the real fence fd to be leaked. */ -#define I915_EXEC_FENCE_OUT (1<<17) +#define I915_EXEC_FENCE_OUT (1ULL<<17) /* * Traditionally the execbuf ioctl has only considered the final element in @@ -1070,13 +1070,13 @@ struct drm_i915_gem_execbuffer2 { * execobject[] as the * batch instead (the default is to use the last * element). */ -#define I915_EXEC_BATCH_FIRST (1<<18) +#define I915_EXEC_BATCH_FIRST (1ULL<<18) /* Setting I915_FENCE_ARRAY implies that num_cliprects and cliprects_ptr * define an array of i915_gem_exec_fence structures which specify a set of * dma fences to wait upon or signal. */ -#define I915_EXEC_FENCE_ARRAY (1<<19) +#define I915_EXEC_FENCE_ARRAY (1ULL<<19) #define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_ARRAY<<1)) @@ -1352,9 +1352,9 @@ struct drm_intel_overlay_put_image { }; /* flags */ -#define I915_OVERLAY_UPDATE_ATTRS (1<<0) -#define I915_OVERLAY_UPDATE_GAMMA (1<<1) -#define I915_OVERLAY_DISABLE_DEST_COLORKEY (1<<2) +#define I915_OVERLAY_UPDATE_ATTRS (1UL<<0) +#define I915_OVERLAY_UPDATE_GAMMA (1UL<<1) +#define I915_OVERLAY_DISABLE_DEST_COLORKEY (1UL<<2) struct drm_intel_overlay_attrs { __u32 flags; __u32 color_key; @@ -1390,11 +1390,11 @@ struct drm_intel_overlay_attrs { * active on a given plane. */ -#define I915_SET_COLORKEY_NONE (1<<0) /* Deprecated. Instead set - * flags==0 to disable colorkeying. - */ -#define I915_SET_COLORKEY_DESTINATION (1<<1) -#define I915_SET_COLORKEY_SOURCE (1<<2) +#define I915_SET_COLORKEY_NONE (1UL<<0) /* Deprecated. Instead set + * flags==0 to disable colorkeying. + */ +#define I915_SET_COLORKEY_DESTINATION (1UL<<1) +#define I915_SET_COLORKEY_SOURCE (1UL<<2) struct drm_intel_sprite_colorkey { __u32 plane_id; __u32 min_value; @@ -1552,9 +1552,9 @@ enum drm_i915_perf_property_id { struct drm_i915_perf_open_param { __u32 flags; -#define I915_PERF_FLAG_FD_CLOEXEC (1<<0) -#define I915_PERF_FLAG_FD_NONBLOCK (1<<1) -#define I915_PERF_FLAG_DISABLED (1<<2) +#define I915_PERF_FLAG_FD_CLOEXEC (1UL<<0) +#define I915_PERF_FLAG_FD_NONBLOCK (1UL<<1) +#define I915_PERF_FLAG_DISABLED (1UL<<2) /** The number of u64 (id, value) pairs */ __u32 num_properties;
We've been dealing a number of 32/64 bits flags issues lately : - 085603287452fc ("drm/i915: Compare user's 64b GTT offset even on 32b") - c58281056a8b26 ("drm/i915: Mark up GTT sizes as u64") - 83b466b1dc5f0b ("drm/i915: Mark pin flags as u64") As userspace and in particular Mesa pulls in the uAPI headers and builds up flags using the uAPI defines we should probably make those more explicitly 32/64bits aware. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> --- include/uapi/drm/i915_drm.h | 90 ++++++++++++++++++------------------- 1 file changed, 45 insertions(+), 45 deletions(-)