On 11/15/19 11:21 AM, Daniel Vetter wrote:
> The current code is a pretty good wtf moment, since we drop the
> reference before we use it. It's not a big deal, because a) we only
> use the pointer, so doesn't blow up and the real reason b) fb->obj[0]
> already holds a full reference for us.
>
> Might as well take the real pointer ins't of complicated games that
> baffle.
>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
> Cc: xen-devel@lists.xenproject.org
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
> ---
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 9 +--------
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
> b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> index ff506bc99414..4f34c5208180 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> @@ -63,14 +63,7 @@ fb_create(struct drm_device *dev, struct drm_file *filp,
> if (IS_ERR_OR_NULL(fb))
> return fb;
>
> - gem_obj = drm_gem_object_lookup(filp, mode_cmd->handles[0]);
> - if (!gem_obj) {
> - DRM_ERROR("Failed to lookup GEM object\n");
> - ret = -ENOENT;
> - goto fail;
> - }
> -
> - drm_gem_object_put_unlocked(gem_obj);
> + gem_obj = fb->obj[0];
>
> ret = xen_drm_front_fb_attach(drm_info->front_info,
> xen_drm_front_dbuf_to_cookie(gem_obj),
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
