Messages in this thread | | | Subject | Re: [PATCH] drm/xen-front: fix pointer casts | From | Oleksandr Andrushchenko <> | Date | Wed, 23 May 2018 14:27:43 +0300 |
| |
On 05/23/2018 02:06 PM, Juergen Gross wrote: > On 23/05/18 12:00, Oleksandr Andrushchenko wrote: >> On 05/23/2018 12:19 PM, Juergen Gross wrote: >>> On 21/05/18 09:39, Oleksandr Andrushchenko wrote: >>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> >>>> >>>> Building for a 32-bit target results in warnings from casting >>>> between a 32-bit pointer and a 64-bit integer. Fix the warnings >>>> by casting those pointers to uintptr_t first. >>>> >>>> Signed-off-by: Oleksandr Andrushchenko >>>> <oleksandr_andrushchenko@epam.com> >>>> --- >>>> drivers/gpu/drm/xen/xen_drm_front.h | 4 ++-- >>>> drivers/gpu/drm/xen/xen_drm_front_shbuf.c | 2 +- >>>> 2 files changed, 3 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/drivers/gpu/drm/xen/xen_drm_front.h >>>> b/drivers/gpu/drm/xen/xen_drm_front.h >>>> index 2c2479b571ae..8e15dbebc4ba 100644 >>>> --- a/drivers/gpu/drm/xen/xen_drm_front.h >>>> +++ b/drivers/gpu/drm/xen/xen_drm_front.h >>>> @@ -126,12 +126,12 @@ struct xen_drm_front_drm_info { >>>> static inline u64 xen_drm_front_fb_to_cookie(struct >>>> drm_framebuffer *fb) >>>> { >>>> - return (u64)fb; >>>> + return (u64)(uintptr_t)fb; >>> Do you really still need the cast to u64? >> Indeed, I can remove (u64) now, thank you >>>> } >>>> static inline u64 xen_drm_front_dbuf_to_cookie(struct >>>> drm_gem_object *gem_obj) >>>> { >>>> - return (u64)gem_obj; >>>> + return (u64)(uintptr_t)gem_obj; >>>> } >>>> int xen_drm_front_mode_set(struct xen_drm_front_drm_pipeline >>>> *pipeline, >>>> diff --git a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c >>>> b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c >>>> index 8099cb343ae3..47fc93847765 100644 >>>> --- a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c >>>> +++ b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c >>>> @@ -122,7 +122,7 @@ static void guest_calc_num_grefs(struct >>>> xen_drm_front_shbuf *buf) >>>> } >>>> #define xen_page_to_vaddr(page) \ >>>> - ((phys_addr_t)pfn_to_kaddr(page_to_xen_pfn(page))) >>>> + ((phys_addr_t)(uintptr_t)pfn_to_kaddr(page_to_xen_pfn(page))) >>> phys_addr_t for a virtual address? >> This is because the resulting value is then passed to gnttab_set_map_op/ >> gnttab_set_unmap_op which expects host address to be passed as >> phys_addr_t addr :( > Okay, but this means the compiler should do the necessary cast when > you drop the cast to phys_addr_t in xen_page_to_vaddr(), as the cast > to uintptr_t is already producing an unsigned integer value which can > easily be promoted to more bits, right? Right, so I can safely use: #define xen_page_to_vaddr(page) \ - ((phys_addr_t)(uintptr_t)pfn_to_kaddr(page_to_xen_pfn(page))) + ((uintptr_t)pfn_to_kaddr(page_to_xen_pfn(page)))
> > Juergen Thank you for your time and comments, Oleksandr
| |