Re: [RFC 2/3] drm: Add helper iterator functions to iterate over plane damage.

[Sinclair Yeh]

On Wed, Apr 04, 2018 at 04:49:07PM -0700, Deepak Rawat wrote:
> With damage property in drm_plane_state, this patch adds helper iterator
> to traverse the damage clips. Iterator will return the damage rectangles
> in framebuffer, plane or crtc coordinates as need by driver
> implementation.
> 
> Signed-off-by: Deepak Rawat 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 122 
> 
>  include/drm/drm_atomic_helper.h |  39 
>  2 files changed, 161 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 55b44e3..355b514 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3865,3 +3865,125 @@ void 
> __drm_atomic_helper_private_obj_duplicate_state(struct drm_private_obj *obj
>   memcpy(state, obj->state, sizeof(*state));
>  }
>  EXPORT_SYMBOL(__drm_atomic_helper_private_obj_duplicate_state);
> +
> +/**
> + * drm_atomic_helper_damage_iter_init - initialize the damage iterator
> + * @iter: The iterator to initialize.
> + * @type: Coordinate type caller is interested in.
> + * @state: plane_state from which to iterate the damage clips.
> + * @hdisplay: Width of crtc on which plane is scanned out.
> + * @vdisplay: Height of crtc on which plane is scanned out.
> + *
> + * Initialize an iterator that is used to translate and clip a set of damage
> + * rectangles in framebuffer coordinates to plane and crtc coordinates. The 
> type
> + * argument specify which type of coordinate to iterate in.
> + *
> + * Returns: 0 on success and negative error code on error. If an error code 
> is
> + * returned then it means the plane state should not update.
> + */
> +int
> +drm_atomic_helper_damage_iter_init(struct drm_atomic_helper_damage_iter 
> *iter,
> +enum drm_atomic_helper_damage_clip_type type,
> +const struct drm_plane_state *state,
> +uint32_t hdisplay, uint32_t vdisplay)
> +{
> + if (!state || !state->crtc || !state->fb)
> + return -EINVAL;
> +
> + memset(iter, 0, sizeof(*iter));
> + iter->clips = (struct drm_rect *)state->damage_clips->data;
> + iter->num_clips = state->num_clips;
> + iter->type = type;
> +
> + /*
> +  * Full update in case of scaling or rotation. In future support for
> +  * scaling/rotating damage clips can be added
> +  */
> + if (state->crtc_w != (state->src_w >> 16) ||
> + state->crtc_h != state->src_h >> 16 || state->rotation != 0) {
> + iter->curr_clip = iter->num_clips;
> + return 0;
> + }
> +
> + iter->fb_src.x1 = 0;
> + iter->fb_src.y1 = 0;
> + iter->fb_src.x2 = state->fb->width;
> + iter->fb_src.y2 = state->fb->height;
> +
> + iter->plane_src.x1 = state->src_x >> 16;
> + iter->plane_src.y1 = state->src_y >> 16;
> + iter->plane_src.x2 = iter->plane_src.x1 + (state->src_w >> 16);
> + iter->plane_src.y2 = iter->plane_src.y1 + (state->src_h >> 16);
> + iter->translate_plane_x = -iter->plane_src.x1;
> + iter->translate_plane_y = -iter->plane_src.y1;
> +
> + /* Clip plane src rect to fb dimensions */
> + drm_rect_intersect(>plane_src, >fb_src);
> +
> + iter->crtc_src.x1 = 0;
> + iter->crtc_src.y1 = 0;
> + iter->crtc_src.x2 = hdisplay;
> + iter->crtc_src.y2 = vdisplay;
> + iter->translate_crtc_x = -(iter->plane_src.x1 - state->crtc_x);
> + iter->translate_crtc_x = -(iter->plane_src.y1 - state->crtc_y);
   ^
I believe you mean translate_crtc_y here


> +
> + /* Clip crtc src rect to plane dimensions */
> + drm_rect_translate(>crtc_src, -iter->translate_crtc_x,
> +-iter->translate_crtc_x);
Also here^

Re: [RFC 2/3] drm: Add helper iterator functions to iterate over plane damage.

[Sinclair Yeh]

On Wed, Apr 04, 2018 at 04:49:07PM -0700, Deepak Rawat wrote:
> With damage property in drm_plane_state, this patch adds helper iterator
> to traverse the damage clips. Iterator will return the damage rectangles
> in framebuffer, plane or crtc coordinates as need by driver
> implementation.
> 
> Signed-off-by: Deepak Rawat 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 122 
> 
>  include/drm/drm_atomic_helper.h |  39 
>  2 files changed, 161 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 55b44e3..355b514 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3865,3 +3865,125 @@ void 
> __drm_atomic_helper_private_obj_duplicate_state(struct drm_private_obj *obj
>   memcpy(state, obj->state, sizeof(*state));
>  }
>  EXPORT_SYMBOL(__drm_atomic_helper_private_obj_duplicate_state);
> +
> +/**
> + * drm_atomic_helper_damage_iter_init - initialize the damage iterator
> + * @iter: The iterator to initialize.
> + * @type: Coordinate type caller is interested in.
> + * @state: plane_state from which to iterate the damage clips.
> + * @hdisplay: Width of crtc on which plane is scanned out.
> + * @vdisplay: Height of crtc on which plane is scanned out.
> + *
> + * Initialize an iterator that is used to translate and clip a set of damage
> + * rectangles in framebuffer coordinates to plane and crtc coordinates. The 
> type
> + * argument specify which type of coordinate to iterate in.
> + *
> + * Returns: 0 on success and negative error code on error. If an error code 
> is
> + * returned then it means the plane state should not update.
> + */
> +int
> +drm_atomic_helper_damage_iter_init(struct drm_atomic_helper_damage_iter 
> *iter,
> +enum drm_atomic_helper_damage_clip_type type,
> +const struct drm_plane_state *state,
> +uint32_t hdisplay, uint32_t vdisplay)
> +{
> + if (!state || !state->crtc || !state->fb)
> + return -EINVAL;
> +
> + memset(iter, 0, sizeof(*iter));
> + iter->clips = (struct drm_rect *)state->damage_clips->data;
> + iter->num_clips = state->num_clips;
> + iter->type = type;
> +
> + /*
> +  * Full update in case of scaling or rotation. In future support for
> +  * scaling/rotating damage clips can be added
> +  */
> + if (state->crtc_w != (state->src_w >> 16) ||
> + state->crtc_h != state->src_h >> 16 || state->rotation != 0) {
> + iter->curr_clip = iter->num_clips;
> + return 0;
> + }
> +
> + iter->fb_src.x1 = 0;
> + iter->fb_src.y1 = 0;
> + iter->fb_src.x2 = state->fb->width;
> + iter->fb_src.y2 = state->fb->height;
> +
> + iter->plane_src.x1 = state->src_x >> 16;
> + iter->plane_src.y1 = state->src_y >> 16;
> + iter->plane_src.x2 = iter->plane_src.x1 + (state->src_w >> 16);
> + iter->plane_src.y2 = iter->plane_src.y1 + (state->src_h >> 16);
> + iter->translate_plane_x = -iter->plane_src.x1;
> + iter->translate_plane_y = -iter->plane_src.y1;
> +
> + /* Clip plane src rect to fb dimensions */
> + drm_rect_intersect(>plane_src, >fb_src);
> +
> + iter->crtc_src.x1 = 0;
> + iter->crtc_src.y1 = 0;
> + iter->crtc_src.x2 = hdisplay;
> + iter->crtc_src.y2 = vdisplay;
> + iter->translate_crtc_x = -(iter->plane_src.x1 - state->crtc_x);
> + iter->translate_crtc_x = -(iter->plane_src.y1 - state->crtc_y);
   ^
I believe you mean translate_crtc_y here


> +
> + /* Clip crtc src rect to plane dimensions */
> + drm_rect_translate(>crtc_src, -iter->translate_crtc_x,
> +-iter->translate_crtc_x);
Also here^

Re: [PATCH] drm/vmwgfx: Use kasprintf

[Sinclair Yeh]

Thanks!

Reviewed-by: Sinclair Yeh <s...@vmware.com>

On Wed, Mar 07, 2018 at 11:33:22PM +0530, Himanshu Jha wrote:
> Use kasprintf instead of combination of kmalloc and sprintf. Also,
> remove the local variables used for storing the string length as they
> are not required now.
> 
> Signed-off-by: Himanshu Jha <himanshujha199...@gmail.com>
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 13 +++--
>  1 file changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> index 9700099..cdff992 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> @@ -328,7 +328,7 @@ int vmw_host_get_guestinfo(const char *guest_info_param,
>  {
>   struct rpc_channel channel;
>   char *msg, *reply = NULL;
> - size_t msg_len, reply_len = 0;
> + size_t reply_len = 0;
>   int ret = 0;
>  
>  
> @@ -338,15 +338,12 @@ int vmw_host_get_guestinfo(const char *guest_info_param,
>   if (!guest_info_param || !length)
>   return -EINVAL;
>  
> - msg_len = strlen(guest_info_param) + strlen("info-get ") + 1;
> - msg = kzalloc(msg_len, GFP_KERNEL);
> + msg = kasprintf(GFP_KERNEL, "info-get %s", guest_info_param);
>   if (!msg) {
>   DRM_ERROR("Cannot allocate memory to get %s", guest_info_param);
>   return -ENOMEM;
>   }
>  
> - sprintf(msg, "info-get %s", guest_info_param);
> -
>   if (vmw_open_channel(, RPCI_PROTOCOL_NUM) ||
>   vmw_send_msg(, msg) ||
>   vmw_recv_msg(, (void *) , _len) ||
> @@ -388,7 +385,6 @@ int vmw_host_log(const char *log)
>  {
>   struct rpc_channel channel;
>   char *msg;
> - int msg_len;
>   int ret = 0;
>  
>  
> @@ -398,15 +394,12 @@ int vmw_host_log(const char *log)
>   if (!log)
>   return ret;
>  
> - msg_len = strlen(log) + strlen("log ") + 1;
> - msg = kzalloc(msg_len, GFP_KERNEL);
> + msg = kasprintf(GFP_KERNEL, "log %s", log);
>   if (!msg) {
>   DRM_ERROR("Cannot allocate memory for log message\n");
>   return -ENOMEM;
>   }
>  
> - sprintf(msg, "log %s", log);
> -
>   if (vmw_open_channel(, RPCI_PROTOCOL_NUM) ||
>   vmw_send_msg(, msg) ||
>   vmw_close_channel()) {
> -- 
> 2.7.4
> 

Re: [PATCH] drm/vmwgfx: Use kasprintf

[Sinclair Yeh]

Thanks!

Reviewed-by: Sinclair Yeh 

On Wed, Mar 07, 2018 at 11:33:22PM +0530, Himanshu Jha wrote:
> Use kasprintf instead of combination of kmalloc and sprintf. Also,
> remove the local variables used for storing the string length as they
> are not required now.
> 
> Signed-off-by: Himanshu Jha 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 13 +++--
>  1 file changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> index 9700099..cdff992 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> @@ -328,7 +328,7 @@ int vmw_host_get_guestinfo(const char *guest_info_param,
>  {
>   struct rpc_channel channel;
>   char *msg, *reply = NULL;
> - size_t msg_len, reply_len = 0;
> + size_t reply_len = 0;
>   int ret = 0;
>  
>  
> @@ -338,15 +338,12 @@ int vmw_host_get_guestinfo(const char *guest_info_param,
>   if (!guest_info_param || !length)
>   return -EINVAL;
>  
> - msg_len = strlen(guest_info_param) + strlen("info-get ") + 1;
> - msg = kzalloc(msg_len, GFP_KERNEL);
> + msg = kasprintf(GFP_KERNEL, "info-get %s", guest_info_param);
>   if (!msg) {
>   DRM_ERROR("Cannot allocate memory to get %s", guest_info_param);
>   return -ENOMEM;
>   }
>  
> - sprintf(msg, "info-get %s", guest_info_param);
> -
>   if (vmw_open_channel(, RPCI_PROTOCOL_NUM) ||
>   vmw_send_msg(, msg) ||
>   vmw_recv_msg(, (void *) , _len) ||
> @@ -388,7 +385,6 @@ int vmw_host_log(const char *log)
>  {
>   struct rpc_channel channel;
>   char *msg;
> - int msg_len;
>   int ret = 0;
>  
>  
> @@ -398,15 +394,12 @@ int vmw_host_log(const char *log)
>   if (!log)
>   return ret;
>  
> - msg_len = strlen(log) + strlen("log ") + 1;
> - msg = kzalloc(msg_len, GFP_KERNEL);
> + msg = kasprintf(GFP_KERNEL, "log %s", log);
>   if (!msg) {
>   DRM_ERROR("Cannot allocate memory for log message\n");
>   return -ENOMEM;
>   }
>  
> - sprintf(msg, "log %s", log);
> -
>   if (vmw_open_channel(, RPCI_PROTOCOL_NUM) ||
>   vmw_send_msg(, msg) ||
>   vmw_close_channel()) {
> -- 
> 2.7.4
> 

Re: [PATCH v.2] 4.15 vmgfx boot warning

[Sinclair Yeh]

This looks okay to me.

On Mon, Dec 18, 2017 at 07:26:03PM -0500, Woody Suwalski wrote:
> The 4.15 drm_atomic_helper driver shows a warning during boot (both 32 and
> 64 bit x86)
> It is caused by a mismatch between the result of vmw_enable_vblank() and
> what the drm_atomic_helper expects:
>    /...
>    ret = drm_crtc_vblank_get(crtc);
>    WARN_ONCE(ret != -EINVAL, "driver forgot to call
> drm_crtc_vblank_off()\n");
>    /...
> 
> Signed-off by: Woody Suwalski 
> 
> --- a/drivers/gpu/drm/drm_atomic_helper.c    2017-12-16 09:55:33.853374561
> -0500
> +++ b/drivers/gpu/drm/drm_atomic_helper.c    2017-12-16 10:55:56.089090752
> -0500
> @@ -889,7 +889,7 @@ disable_outputs(struct drm_device *dev,
>          continue;
> 
>      ret = drm_crtc_vblank_get(crtc);
> -        WARN_ONCE(ret != -EINVAL, "driver forgot to call
> drm_crtc_vblank_off()\n");
> +        WARN_ONCE((ret != -EINVAL && ret != -ENOSYS), "driver forgot to
> call drm_crtc_vblank_off()\n");
>      if (ret == 0)
>          drm_crtc_vblank_put(crtc);
>  }
> 

> --- a/drivers/gpu/drm/drm_atomic_helper.c 2017-12-16 09:55:33.853374561 
> -0500
> +++ b/drivers/gpu/drm/drm_atomic_helper.c 2017-12-16 10:55:56.089090752 
> -0500
> @@ -889,7 +889,7 @@ disable_outputs(struct drm_device *dev,
>   continue;
>  
>   ret = drm_crtc_vblank_get(crtc);
> - WARN_ONCE(ret != -EINVAL, "driver forgot to call 
> drm_crtc_vblank_off()\n");
> + WARN_ONCE((ret != -EINVAL && ret != -ENOSYS), "driver forgot to 
> call drm_crtc_vblank_off()\n");
>   if (ret == 0)
>   drm_crtc_vblank_put(crtc);
>   }

Re: [PATCH v.2] 4.15 vmgfx boot warning

[Sinclair Yeh]

This looks okay to me.

On Mon, Dec 18, 2017 at 07:26:03PM -0500, Woody Suwalski wrote:
> The 4.15 drm_atomic_helper driver shows a warning during boot (both 32 and
> 64 bit x86)
> It is caused by a mismatch between the result of vmw_enable_vblank() and
> what the drm_atomic_helper expects:
>    /...
>    ret = drm_crtc_vblank_get(crtc);
>    WARN_ONCE(ret != -EINVAL, "driver forgot to call
> drm_crtc_vblank_off()\n");
>    /...
> 
> Signed-off by: Woody Suwalski 
> 
> --- a/drivers/gpu/drm/drm_atomic_helper.c    2017-12-16 09:55:33.853374561
> -0500
> +++ b/drivers/gpu/drm/drm_atomic_helper.c    2017-12-16 10:55:56.089090752
> -0500
> @@ -889,7 +889,7 @@ disable_outputs(struct drm_device *dev,
>          continue;
> 
>      ret = drm_crtc_vblank_get(crtc);
> -        WARN_ONCE(ret != -EINVAL, "driver forgot to call
> drm_crtc_vblank_off()\n");
> +        WARN_ONCE((ret != -EINVAL && ret != -ENOSYS), "driver forgot to
> call drm_crtc_vblank_off()\n");
>      if (ret == 0)
>          drm_crtc_vblank_put(crtc);
>  }
> 

> --- a/drivers/gpu/drm/drm_atomic_helper.c 2017-12-16 09:55:33.853374561 
> -0500
> +++ b/drivers/gpu/drm/drm_atomic_helper.c 2017-12-16 10:55:56.089090752 
> -0500
> @@ -889,7 +889,7 @@ disable_outputs(struct drm_device *dev,
>   continue;
>  
>   ret = drm_crtc_vblank_get(crtc);
> - WARN_ONCE(ret != -EINVAL, "driver forgot to call 
> drm_crtc_vblank_off()\n");
> + WARN_ONCE((ret != -EINVAL && ret != -ENOSYS), "driver forgot to 
> call drm_crtc_vblank_off()\n");
>   if (ret == 0)
>   drm_crtc_vblank_put(crtc);
>   }

Re: [PATCH] 4.15 vmgfx boot warning

[Sinclair Yeh]

Hi Woody,

On Wed, Nov 22, 2017 at 04:05:50PM -0500, Woody Suwalski wrote:
> The 4.15 vmwgfx driver shows a warning during boot (32 bit x86)
> It is caused by a mismatch between the result of vmw_enable_vblank() and
> what the drm_atomic_helper expects:
>    /...
>    ret = drm_crtc_vblank_get(crtc);
>    WARN_ONCE(ret != -EINVAL, "driver forgot to call
> drm_crtc_vblank_off()\n");

This doesn't apply to us because we don't have vblank support, and so
-ENOSYS seems to be the right error.

In the commit message for 84014b0a39ee, it does state a check for this
condition, but the check itself is based on dev->irq_enabled.

Is there another way to check for vblank support?



>    /...
> 
> Signed-off by: Woody Suwalski 
> 
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c    2017-11-22 15:29:46.511674079
> -0500
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c    2017-11-22 15:30:35.344559592
> -0500
> @@ -1869,7 +1869,7 @@ u32 vmw_get_vblank_counter(struct drm_de
>   */
>  int vmw_enable_vblank(struct drm_device *dev, unsigned int pipe)
>  {
> -    return -ENOSYS;
> +    return -EINVAL;
>  }
> 
>  /**
> 

Re: [PATCH] 4.15 vmgfx boot warning

[Sinclair Yeh]

Hi Woody,

On Wed, Nov 22, 2017 at 04:05:50PM -0500, Woody Suwalski wrote:
> The 4.15 vmwgfx driver shows a warning during boot (32 bit x86)
> It is caused by a mismatch between the result of vmw_enable_vblank() and
> what the drm_atomic_helper expects:
>    /...
>    ret = drm_crtc_vblank_get(crtc);
>    WARN_ONCE(ret != -EINVAL, "driver forgot to call
> drm_crtc_vblank_off()\n");

This doesn't apply to us because we don't have vblank support, and so
-ENOSYS seems to be the right error.

In the commit message for 84014b0a39ee, it does state a check for this
condition, but the check itself is based on dev->irq_enabled.

Is there another way to check for vblank support?



>    /...
> 
> Signed-off by: Woody Suwalski 
> 
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c    2017-11-22 15:29:46.511674079
> -0500
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c    2017-11-22 15:30:35.344559592
> -0500
> @@ -1869,7 +1869,7 @@ u32 vmw_get_vblank_counter(struct drm_de
>   */
>  int vmw_enable_vblank(struct drm_device *dev, unsigned int pipe)
>  {
> -    return -ENOSYS;
> +    return -EINVAL;
>  }
> 
>  /**
> 

Re: [PATCH] vmwgfx: use monotonic event timestamps

[Sinclair Yeh]

This looks okay to me.  Although we should change eaction->tv_* type
to 64-bit as well.

I'll roll this in to our next pull request.

thanks,

Sinclair


On Mon, Nov 27, 2017 at 12:16:19PM +0100, Arnd Bergmann wrote:
> DRM_VMW_EVENT_FENCE_SIGNALED (struct drm_vmw_event_fence) and
> DRM_EVENT_VBLANK (struct drm_event_vblank) pass timestamps in 32-bit
> seconds/microseconds format.
> 
> As of commit c61eef726a78 ("drm: add support for monotonic vblank
> timestamps"), other DRM drivers use monotonic times for drm_event_vblank,
> but vmwgfx still uses CLOCK_REALTIME for both events, which suffers from
> the y2038/y2106 overflow as well as time jumps.
> 
> For consistency, this changes vmwgfx to use ktime_get_ts64 as well,
> which solves those problems and avoids the deprecated do_gettimeofday()
> function.
> 
> This should be transparent to to user space, as long as it doesn't
> compare the time against the result of gettimeofday().
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> index d6b1c509ae01..55214d0da66e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> @@ -897,11 +897,12 @@ static void vmw_event_fence_action_seq_passed(struct 
> vmw_fence_action *action)
>   spin_lock_irq(>event_lock);
>  
>   if (likely(eaction->tv_sec != NULL)) {
> - struct timeval tv;
> + struct timespec64 ts;
>  
> - do_gettimeofday();
> - *eaction->tv_sec = tv.tv_sec;
> - *eaction->tv_usec = tv.tv_usec;
> + ktime_get_ts64();
> + /* monotonic time, so no y2038 overflow */
> + *eaction->tv_sec = ts.tv_sec;
> + *eaction->tv_usec = ts.tv_nsec / NSEC_PER_USEC;
>   }
>  
>   drm_send_event_locked(dev, eaction->event);
> -- 
> 2.9.0
> 

Re: [PATCH] vmwgfx: use monotonic event timestamps

[Sinclair Yeh]

This looks okay to me.  Although we should change eaction->tv_* type
to 64-bit as well.

I'll roll this in to our next pull request.

thanks,

Sinclair


On Mon, Nov 27, 2017 at 12:16:19PM +0100, Arnd Bergmann wrote:
> DRM_VMW_EVENT_FENCE_SIGNALED (struct drm_vmw_event_fence) and
> DRM_EVENT_VBLANK (struct drm_event_vblank) pass timestamps in 32-bit
> seconds/microseconds format.
> 
> As of commit c61eef726a78 ("drm: add support for monotonic vblank
> timestamps"), other DRM drivers use monotonic times for drm_event_vblank,
> but vmwgfx still uses CLOCK_REALTIME for both events, which suffers from
> the y2038/y2106 overflow as well as time jumps.
> 
> For consistency, this changes vmwgfx to use ktime_get_ts64 as well,
> which solves those problems and avoids the deprecated do_gettimeofday()
> function.
> 
> This should be transparent to to user space, as long as it doesn't
> compare the time against the result of gettimeofday().
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> index d6b1c509ae01..55214d0da66e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> @@ -897,11 +897,12 @@ static void vmw_event_fence_action_seq_passed(struct 
> vmw_fence_action *action)
>   spin_lock_irq(>event_lock);
>  
>   if (likely(eaction->tv_sec != NULL)) {
> - struct timeval tv;
> + struct timespec64 ts;
>  
> - do_gettimeofday();
> - *eaction->tv_sec = tv.tv_sec;
> - *eaction->tv_usec = tv.tv_usec;
> + ktime_get_ts64();
> + /* monotonic time, so no y2038 overflow */
> + *eaction->tv_sec = ts.tv_sec;
> + *eaction->tv_usec = ts.tv_nsec / NSEC_PER_USEC;
>   }
>  
>   drm_send_event_locked(dev, eaction->event);
> -- 
> 2.9.0
> 

Re: [PATCH] drm: vmwgfx: constify vmw_fence_ops

[Sinclair Yeh]

On Wed, Aug 30, 2017 at 10:30:24AM +0200, Daniel Vetter wrote:
> On Wed, Aug 30, 2017 at 08:21:46AM +0200, Thomas Hellstrom wrote:
> > On 08/30/2017 07:47 AM, Arvind Yadav wrote:
> > > vmw_fence_ops are not supposed to change at runtime. Functions
> > > "dma_fence_init" working with const vmw_fence_ops provided
> > > by . So mark the non-const structs as const.
> > > 
> > > Signed-off-by: Arvind Yadav 
> > > ---
> > >   drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
> > > b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> > > index b8bc5bc..abc5f03 100644
> > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> > > @@ -225,7 +225,7 @@ static long vmw_fence_wait(struct dma_fence *f, bool 
> > > intr, signed long timeout)
> > >   return ret;
> > >   }
> > > -static struct dma_fence_ops vmw_fence_ops = {
> > > +static const struct dma_fence_ops vmw_fence_ops = {
> > >   .get_driver_name = vmw_fence_get_driver_name,
> > >   .get_timeline_name = vmw_fence_get_timeline_name,
> > >   .enable_signaling = vmw_fence_enable_signaling,
> > 
> > Reviewed-by: Thomas Hellstrom 
> 
> Does this mean you'll merge it, or does this mean you'll expect someone
> else to merge this?

Yes, we have this queued and will go out in the next pull request.

Re: [PATCH] drm: vmwgfx: constify vmw_fence_ops

[Sinclair Yeh]

On Wed, Aug 30, 2017 at 10:30:24AM +0200, Daniel Vetter wrote:
> On Wed, Aug 30, 2017 at 08:21:46AM +0200, Thomas Hellstrom wrote:
> > On 08/30/2017 07:47 AM, Arvind Yadav wrote:
> > > vmw_fence_ops are not supposed to change at runtime. Functions
> > > "dma_fence_init" working with const vmw_fence_ops provided
> > > by . So mark the non-const structs as const.
> > > 
> > > Signed-off-by: Arvind Yadav 
> > > ---
> > >   drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
> > > b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> > > index b8bc5bc..abc5f03 100644
> > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> > > @@ -225,7 +225,7 @@ static long vmw_fence_wait(struct dma_fence *f, bool 
> > > intr, signed long timeout)
> > >   return ret;
> > >   }
> > > -static struct dma_fence_ops vmw_fence_ops = {
> > > +static const struct dma_fence_ops vmw_fence_ops = {
> > >   .get_driver_name = vmw_fence_get_driver_name,
> > >   .get_timeline_name = vmw_fence_get_timeline_name,
> > >   .enable_signaling = vmw_fence_enable_signaling,
> > 
> > Reviewed-by: Thomas Hellstrom 
> 
> Does this mean you'll merge it, or does this mean you'll expect someone
> else to merge this?

Yes, we have this queued and will go out in the next pull request.

Re: linux-next: Signed-off-by missing for commits in the drm tree

[Sinclair Yeh]

On Tue, Aug 29, 2017 at 11:44:13AM +1000, Stephen Rothwell wrote:
> Hi Dave,
> 
> Commits
> 
>   461e60ea1119 ("drm/exynos/decon5433: use mode info stored in CRTC to detect 
> i80 mode")
>   ac60944ccf23 ("drm/exynos: consistent use of cpp")
>   e300173f0616 ("drm/vmwgfx: Don't use drm_irq_[un]install")

This one is Reviewed-by: Sinclair Yeh <s...@vmware.com>

>   ef369904aaf7 ("drm/vmwgfx: Move irq bottom half processing to threads")
>   65b97a2bec2f ("drm/vmwgfx: Restart command buffers after errors")
>   5f55be5f306a ("drm/vmwgfx: Support the NOP_ERROR command")
>   1f1a36cc4d49 ("drm/vmwgfx: Fix incorrect command header offset at restart")a

For these 4, I thought SOB the author is enough, but if not, I can add SOB.

Is it easier for you to add those, or would you like me to rebase and send out 
another
pull request?

thanks,

Sinclair

Re: linux-next: Signed-off-by missing for commits in the drm tree

[Sinclair Yeh]

On Tue, Aug 29, 2017 at 11:44:13AM +1000, Stephen Rothwell wrote:
> Hi Dave,
> 
> Commits
> 
>   461e60ea1119 ("drm/exynos/decon5433: use mode info stored in CRTC to detect 
> i80 mode")
>   ac60944ccf23 ("drm/exynos: consistent use of cpp")
>   e300173f0616 ("drm/vmwgfx: Don't use drm_irq_[un]install")

This one is Reviewed-by: Sinclair Yeh 

>   ef369904aaf7 ("drm/vmwgfx: Move irq bottom half processing to threads")
>   65b97a2bec2f ("drm/vmwgfx: Restart command buffers after errors")
>   5f55be5f306a ("drm/vmwgfx: Support the NOP_ERROR command")
>   1f1a36cc4d49 ("drm/vmwgfx: Fix incorrect command header offset at restart")a

For these 4, I thought SOB the author is enough, but if not, I can add SOB.

Is it easier for you to add those, or would you like me to rebase and send out 
another
pull request?

thanks,

Sinclair

Re: [PATCH 2/5] drm: vmwgfx: constify pci_device_id.

[Sinclair Yeh]

Thanks.  Queued.

On Sat, Jul 15, 2017 at 12:44:53PM +0530, Arvind Yadav wrote:
> pci_device_id are not supposed to change at runtime. All functions
> working with pci_device_id provided by  work with
> const pci_device_id. So mark the non-const structs as const.
> 
> File size before:
>text  data bss dec hex filename
>   13765   800  20   1458538f9 gpu/drm/vmwgfx/vmwgfx_drv.o
> 
> File size After adding 'const':
>text  data bss dec hex filename
>   13829   736  20   1458538f9 gpu/drm/vmwgfx/vmwgfx_drv.o
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 4a64155..f5fe28f 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -227,7 +227,7 @@ static const struct drm_ioctl_desc vmw_ioctls[] = {
> DRM_AUTH | DRM_RENDER_ALLOW),
>  };
>  
> -static struct pci_device_id vmw_pci_id_list[] = {
> +static const struct pci_device_id vmw_pci_id_list[] = {
>   {0x15ad, 0x0405, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VMWGFX_CHIP_SVGAII},
>   {0, 0, 0}
>  };
> -- 
> 2.7.4
> 

Re: [PATCH 2/5] drm: vmwgfx: constify pci_device_id.

[Sinclair Yeh]

Thanks.  Queued.

On Sat, Jul 15, 2017 at 12:44:53PM +0530, Arvind Yadav wrote:
> pci_device_id are not supposed to change at runtime. All functions
> working with pci_device_id provided by  work with
> const pci_device_id. So mark the non-const structs as const.
> 
> File size before:
>text  data bss dec hex filename
>   13765   800  20   1458538f9 gpu/drm/vmwgfx/vmwgfx_drv.o
> 
> File size After adding 'const':
>text  data bss dec hex filename
>   13829   736  20   1458538f9 gpu/drm/vmwgfx/vmwgfx_drv.o
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 4a64155..f5fe28f 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -227,7 +227,7 @@ static const struct drm_ioctl_desc vmw_ioctls[] = {
> DRM_AUTH | DRM_RENDER_ALLOW),
>  };
>  
> -static struct pci_device_id vmw_pci_id_list[] = {
> +static const struct pci_device_id vmw_pci_id_list[] = {
>   {0x15ad, 0x0405, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VMWGFX_CHIP_SVGAII},
>   {0, 0, 0}
>  };
> -- 
> 2.7.4
> 

Re: [PATCH, RESEND 03/14] drm/vmwgfx: avoid gcc-7 parentheses warning

[Sinclair Yeh]

On Fri, Jul 14, 2017 at 10:28:29PM +0200, Arnd Bergmann wrote:
> On Fri, Jul 14, 2017 at 9:23 PM, Linus Torvalds
>  wrote:
> > On Fri, Jul 14, 2017 at 12:21 PM, Linus Torvalds
> >  wrote:
> >>
> >> NAK. This takes unintentionally insane code and turns it intentionally
> >> insane. Any non-zero return is considered an error.
> >>
> >> The right fix is almost certainly to just return -EINVAL unconditionally.

Correct.  I'll fix this.

> >
> > Btw, this is why I hate compiler warning fix patch series. Even when
> > they don't actually break the code (and sometimes they do that too),
> > they can actually end up making the code worse.
> 
> I generally agree, and this is also why I held up sending patches for the
> -Wformat warnings until you brought those up. I also frequently send
> patches for recently introduced warnings, which tend to have a better
> chance of getting reviewed by the person that just introduced the code,
> to catch this kind of mistake in my patches.
> 
> I also regularly run into cases where I send a correct patch and find
> that another broken patch has been applied the following day ;-)
> 
> > The *intent* of that code was to return zero for the CAP_SYS_ADMIN.
> > But the code has never done that in its lifetime and nobody ever
> > noticed, so clearly the code shouldn't even have tried.
> 
> Makes sense, yes. In this case, the review process has failed as
> well, as one of the maintainers even gave an Ack on the wrong patch,
> and then the patch got dropped without any feedback.

I've done some digging and noticed that my -fixes pull request
didn't get picked up last December.  It's most likely because I
initially made an address typo in the original request, and then
followed it up with a direct email with the correct address.

Sinclair

Re: [PATCH, RESEND 03/14] drm/vmwgfx: avoid gcc-7 parentheses warning

[Sinclair Yeh]

On Fri, Jul 14, 2017 at 10:28:29PM +0200, Arnd Bergmann wrote:
> On Fri, Jul 14, 2017 at 9:23 PM, Linus Torvalds
>  wrote:
> > On Fri, Jul 14, 2017 at 12:21 PM, Linus Torvalds
> >  wrote:
> >>
> >> NAK. This takes unintentionally insane code and turns it intentionally
> >> insane. Any non-zero return is considered an error.
> >>
> >> The right fix is almost certainly to just return -EINVAL unconditionally.

Correct.  I'll fix this.

> >
> > Btw, this is why I hate compiler warning fix patch series. Even when
> > they don't actually break the code (and sometimes they do that too),
> > they can actually end up making the code worse.
> 
> I generally agree, and this is also why I held up sending patches for the
> -Wformat warnings until you brought those up. I also frequently send
> patches for recently introduced warnings, which tend to have a better
> chance of getting reviewed by the person that just introduced the code,
> to catch this kind of mistake in my patches.
> 
> I also regularly run into cases where I send a correct patch and find
> that another broken patch has been applied the following day ;-)
> 
> > The *intent* of that code was to return zero for the CAP_SYS_ADMIN.
> > But the code has never done that in its lifetime and nobody ever
> > noticed, so clearly the code shouldn't even have tried.
> 
> Makes sense, yes. In this case, the review process has failed as
> well, as one of the maintainers even gave an Ack on the wrong patch,
> and then the patch got dropped without any feedback.

I've done some digging and noticed that my -fixes pull request
didn't get picked up last December.  It's most likely because I
initially made an address typo in the original request, and then
followed it up with a direct email with the correct address.

Sinclair

Re: [PATCH] drm: ttm: vmwgfx: dma-buf: Constify ttm_place structures.

[Sinclair Yeh]

Looks good.  Thanks.

I've queued this for my next pull request.

On Sun, Jul 02, 2017 at 01:26:55PM +0530, Arvind Yadav wrote:
> ttm_place are not supposed to change at runtime. All functions
> working with ttm_place provided by  work
> with const ttm_place. So mark the non-const structs as const.
> 
> File size before:
>text  data bss dec hex filename
>3172   796  163984 f90 
> drivers/gpu/drm/vmwgfx/vmwgfx_buffer.o
> 
> File size After adding 'const':
>text  data bss dec hex filename
>3456   512  163984 f90 
> drivers/gpu/drm/vmwgfx/vmwgfx_buffer.o
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> index 35bf781..c705632 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> @@ -30,49 +30,49 @@
>  #include 
>  #include 
>  
> -static struct ttm_place vram_placement_flags = {
> +static const struct ttm_place vram_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = TTM_PL_FLAG_VRAM | TTM_PL_FLAG_CACHED
>  };
>  
> -static struct ttm_place vram_ne_placement_flags = {
> +static const struct ttm_place vram_ne_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = TTM_PL_FLAG_VRAM | TTM_PL_FLAG_CACHED | TTM_PL_FLAG_NO_EVICT
>  };
>  
> -static struct ttm_place sys_placement_flags = {
> +static const struct ttm_place sys_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED
>  };
>  
> -static struct ttm_place sys_ne_placement_flags = {
> +static const struct ttm_place sys_ne_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED | TTM_PL_FLAG_NO_EVICT
>  };
>  
> -static struct ttm_place gmr_placement_flags = {
> +static const struct ttm_place gmr_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = VMW_PL_FLAG_GMR | TTM_PL_FLAG_CACHED
>  };
>  
> -static struct ttm_place gmr_ne_placement_flags = {
> +static const struct ttm_place gmr_ne_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = VMW_PL_FLAG_GMR | TTM_PL_FLAG_CACHED | TTM_PL_FLAG_NO_EVICT
>  };
>  
> -static struct ttm_place mob_placement_flags = {
> +static const struct ttm_place mob_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = VMW_PL_FLAG_MOB | TTM_PL_FLAG_CACHED
>  };
>  
> -static struct ttm_place mob_ne_placement_flags = {
> +static const struct ttm_place mob_ne_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = VMW_PL_FLAG_MOB | TTM_PL_FLAG_CACHED | TTM_PL_FLAG_NO_EVICT
> @@ -85,7 +85,7 @@ struct ttm_placement vmw_vram_placement = {
>   .busy_placement = _placement_flags
>  };
>  
> -static struct ttm_place vram_gmr_placement_flags[] = {
> +static const struct ttm_place vram_gmr_placement_flags[] = {
>   {
>   .fpfn = 0,
>   .lpfn = 0,
> @@ -97,7 +97,7 @@ static struct ttm_place vram_gmr_placement_flags[] = {
>   }
>  };
>  
> -static struct ttm_place gmr_vram_placement_flags[] = {
> +static const struct ttm_place gmr_vram_placement_flags[] = {
>   {
>   .fpfn = 0,
>   .lpfn = 0,
> @@ -116,7 +116,7 @@ struct ttm_placement vmw_vram_gmr_placement = {
>   .busy_placement = _placement_flags
>  };
>  
> -static struct ttm_place vram_gmr_ne_placement_flags[] = {
> +static const struct ttm_place vram_gmr_ne_placement_flags[] = {
>   {
>   .fpfn = 0,
>   .lpfn = 0,
> @@ -165,7 +165,7 @@ struct ttm_placement vmw_sys_ne_placement = {
>   .busy_placement = _ne_placement_flags
>  };
>  
> -static struct ttm_place evictable_placement_flags[] = {
> +static const struct ttm_place evictable_placement_flags[] = {
>   {
>   .fpfn = 0,
>   .lpfn = 0,
> -- 
> 2.7.4
> 

Re: [PATCH] drm: ttm: vmwgfx: dma-buf: Constify ttm_place structures.

[Sinclair Yeh]

Looks good.  Thanks.

I've queued this for my next pull request.

On Sun, Jul 02, 2017 at 01:26:55PM +0530, Arvind Yadav wrote:
> ttm_place are not supposed to change at runtime. All functions
> working with ttm_place provided by  work
> with const ttm_place. So mark the non-const structs as const.
> 
> File size before:
>text  data bss dec hex filename
>3172   796  163984 f90 
> drivers/gpu/drm/vmwgfx/vmwgfx_buffer.o
> 
> File size After adding 'const':
>text  data bss dec hex filename
>3456   512  163984 f90 
> drivers/gpu/drm/vmwgfx/vmwgfx_buffer.o
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> index 35bf781..c705632 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> @@ -30,49 +30,49 @@
>  #include 
>  #include 
>  
> -static struct ttm_place vram_placement_flags = {
> +static const struct ttm_place vram_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = TTM_PL_FLAG_VRAM | TTM_PL_FLAG_CACHED
>  };
>  
> -static struct ttm_place vram_ne_placement_flags = {
> +static const struct ttm_place vram_ne_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = TTM_PL_FLAG_VRAM | TTM_PL_FLAG_CACHED | TTM_PL_FLAG_NO_EVICT
>  };
>  
> -static struct ttm_place sys_placement_flags = {
> +static const struct ttm_place sys_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED
>  };
>  
> -static struct ttm_place sys_ne_placement_flags = {
> +static const struct ttm_place sys_ne_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED | TTM_PL_FLAG_NO_EVICT
>  };
>  
> -static struct ttm_place gmr_placement_flags = {
> +static const struct ttm_place gmr_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = VMW_PL_FLAG_GMR | TTM_PL_FLAG_CACHED
>  };
>  
> -static struct ttm_place gmr_ne_placement_flags = {
> +static const struct ttm_place gmr_ne_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = VMW_PL_FLAG_GMR | TTM_PL_FLAG_CACHED | TTM_PL_FLAG_NO_EVICT
>  };
>  
> -static struct ttm_place mob_placement_flags = {
> +static const struct ttm_place mob_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = VMW_PL_FLAG_MOB | TTM_PL_FLAG_CACHED
>  };
>  
> -static struct ttm_place mob_ne_placement_flags = {
> +static const struct ttm_place mob_ne_placement_flags = {
>   .fpfn = 0,
>   .lpfn = 0,
>   .flags = VMW_PL_FLAG_MOB | TTM_PL_FLAG_CACHED | TTM_PL_FLAG_NO_EVICT
> @@ -85,7 +85,7 @@ struct ttm_placement vmw_vram_placement = {
>   .busy_placement = _placement_flags
>  };
>  
> -static struct ttm_place vram_gmr_placement_flags[] = {
> +static const struct ttm_place vram_gmr_placement_flags[] = {
>   {
>   .fpfn = 0,
>   .lpfn = 0,
> @@ -97,7 +97,7 @@ static struct ttm_place vram_gmr_placement_flags[] = {
>   }
>  };
>  
> -static struct ttm_place gmr_vram_placement_flags[] = {
> +static const struct ttm_place gmr_vram_placement_flags[] = {
>   {
>   .fpfn = 0,
>   .lpfn = 0,
> @@ -116,7 +116,7 @@ struct ttm_placement vmw_vram_gmr_placement = {
>   .busy_placement = _placement_flags
>  };
>  
> -static struct ttm_place vram_gmr_ne_placement_flags[] = {
> +static const struct ttm_place vram_gmr_ne_placement_flags[] = {
>   {
>   .fpfn = 0,
>   .lpfn = 0,
> @@ -165,7 +165,7 @@ struct ttm_placement vmw_sys_ne_placement = {
>   .busy_placement = _ne_placement_flags
>  };
>  
> -static struct ttm_place evictable_placement_flags[] = {
> +static const struct ttm_place evictable_placement_flags[] = {
>   {
>   .fpfn = 0,
>   .lpfn = 0,
> -- 
> 2.7.4
> 

Re: [PATCH] drm/vmwgfx: fix spelling mistake "exeeds" -> "exceeds"

[Sinclair Yeh]

Thanks.  Reviewed and queued.

On Sat, May 27, 2017 at 07:52:30PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in DRM_ERROR error message.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index 5900cff5bbc3..cee803c7d077 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -1492,7 +1492,7 @@ int vmw_surface_gb_priv_define(struct drm_device *dev,
>dev_priv->stdu_max_height);
>  
>   if (size.width > max_width || size.height > max_height) {
> - DRM_ERROR("%ux%u\n, exeeds max surface size %ux%u",
> + DRM_ERROR("%ux%u\n, exceeds max surface size %ux%u",
> size.width, size.height,
> max_width, max_height);
>   return -EINVAL;
> -- 
> 2.11.0
> 

Re: [PATCH] drm/vmwgfx: fix spelling mistake "exeeds" -> "exceeds"

[Sinclair Yeh]

Thanks.  Reviewed and queued.

On Sat, May 27, 2017 at 07:52:30PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in DRM_ERROR error message.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index 5900cff5bbc3..cee803c7d077 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -1492,7 +1492,7 @@ int vmw_surface_gb_priv_define(struct drm_device *dev,
>dev_priv->stdu_max_height);
>  
>   if (size.width > max_width || size.height > max_height) {
> - DRM_ERROR("%ux%u\n, exeeds max surface size %ux%u",
> + DRM_ERROR("%ux%u\n, exceeds max surface size %ux%u",
> size.width, size.height,
> max_width, max_height);
>   return -EINVAL;
> -- 
> 2.11.0
> 

Re: [PATCH v3] drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI

[Sinclair Yeh]

vmwgfx part: Reviewed-by: Sinclair Yeh <s...@vmware.com>

On Wed, May 17, 2017 at 09:39:11PM -0400, Robert Foss wrote:
> Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI
> as a convenience.
> 
> Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up
> through the atomic API, but realizing that userspace is likely to take
> shortcuts and assume that the enum values are what is sent over the
> wire.
> 
> As a result these defines are provided purely as a convenience to
> userspace applications.
> 
> Signed-off-by: Robert Foss <robert.f...@collabora.com>
> ---
> Changes since v2:
>  - Changed define prefix from DRM_MODE_PROP_ to DRM_MODE_
>  - Fix compilation errors
>  - Changed comment formatting
>  - Deduplicated comment lines
>  - Clarified DRM_MODE_PROP_REFLECT_ comment
> 
> Changes since v1:
>  - Moved defines from drm.h to drm_mode.h
>  - Changed define prefix from DRM_ to DRM_MODE_PROP_ 
>  - Updated uses of the defines to the new prefix
>  - Removed include from drm_rect.c
>  - Stopped using the BIT() macro 
> 
>  drivers/gpu/drm/arm/malidp_drv.h|  2 +-
>  drivers/gpu/drm/arm/malidp_planes.c | 18 -
>  drivers/gpu/drm/armada/armada_overlay.c |  2 +-
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 20 +-
>  drivers/gpu/drm/drm_atomic.c|  2 +-
>  drivers/gpu/drm/drm_atomic_helper.c |  2 +-
>  drivers/gpu/drm/drm_blend.c | 43 ++---
>  drivers/gpu/drm/drm_fb_helper.c |  4 +-
>  drivers/gpu/drm/drm_plane_helper.c  |  2 +-
>  drivers/gpu/drm/drm_rect.c  | 36 +-
>  drivers/gpu/drm/i915/i915_debugfs.c | 14 +++
>  drivers/gpu/drm/i915/intel_atomic_plane.c   |  6 +--
>  drivers/gpu/drm/i915/intel_display.c| 50 
> -
>  drivers/gpu/drm/i915/intel_fbc.c|  2 +-
>  drivers/gpu/drm/i915/intel_fbdev.c  |  2 +-
>  drivers/gpu/drm/i915/intel_sprite.c | 20 +-
>  drivers/gpu/drm/imx/ipuv3-plane.c   |  2 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   | 30 +++
>  drivers/gpu/drm/nouveau/nv50_display.c  |  2 +-
>  drivers/gpu/drm/omapdrm/omap_drv.c  |  4 +-
>  drivers/gpu/drm/omapdrm/omap_fb.c   | 18 -
>  drivers/gpu/drm/omapdrm/omap_plane.c| 16 
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  4 +-
>  include/drm/drm_blend.h | 21 +--
>  include/uapi/drm/drm_mode.h | 49 +++-
>  25 files changed, 201 insertions(+), 170 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.h 
> b/drivers/gpu/drm/arm/malidp_drv.h
> index 040311ffcaec..2e2033140efc 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.h
> +++ b/drivers/gpu/drm/arm/malidp_drv.h
> @@ -65,6 +65,6 @@ void malidp_de_planes_destroy(struct drm_device *drm);
>  int malidp_crtc_init(struct drm_device *drm);
>  
>  /* often used combination of rotational bits */
> -#define MALIDP_ROTATED_MASK  (DRM_ROTATE_90 | DRM_ROTATE_270)
> +#define MALIDP_ROTATED_MASK  (DRM_MODE_ROTATE_90 | DRM_MODE_ROTATE_270)
>  
>  #endif  /* __MALIDP_DRV_H__ */
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 814fda23cead..063a8d2b0be3 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -80,7 +80,7 @@ static void malidp_plane_reset(struct drm_plane *plane)
>   state = kzalloc(sizeof(*state), GFP_KERNEL);
>   if (state) {
>   state->base.plane = plane;
> - state->base.rotation = DRM_ROTATE_0;
> + state->base.rotation = DRM_MODE_ROTATE_0;
>   plane->state = >base;
>   }
>  }
> @@ -221,7 +221,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
>   return ret;
>  
>   /* packed RGB888 / BGR888 can't be rotated or flipped */
> - if (state->rotation != DRM_ROTATE_0 &&
> + if (state->rotation != DRM_MODE_ROTATE_0 &&
>   (fb->format->format == DRM_FORMAT_RGB888 ||
>fb->format->format == DRM_FORMAT_BGR888))
>   return -EINVAL;
> @@ -315,12 +315,12 @@ static void malidp_de_plane_update(struct drm_plane 
> *plane,
>   val &= ~LAYER_ROT_MASK;
>  
>   /* setup the rotation and axis flip bits */
> - if (plane->state->rotation & DRM_ROTATE_MASK)
> - val |= ilog2(plane->state->rotation & DRM_ROTATE_MASK)

Re: [PATCH v3] drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI

[Sinclair Yeh]

vmwgfx part: Reviewed-by: Sinclair Yeh 

On Wed, May 17, 2017 at 09:39:11PM -0400, Robert Foss wrote:
> Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI
> as a convenience.
> 
> Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up
> through the atomic API, but realizing that userspace is likely to take
> shortcuts and assume that the enum values are what is sent over the
> wire.
> 
> As a result these defines are provided purely as a convenience to
> userspace applications.
> 
> Signed-off-by: Robert Foss 
> ---
> Changes since v2:
>  - Changed define prefix from DRM_MODE_PROP_ to DRM_MODE_
>  - Fix compilation errors
>  - Changed comment formatting
>  - Deduplicated comment lines
>  - Clarified DRM_MODE_PROP_REFLECT_ comment
> 
> Changes since v1:
>  - Moved defines from drm.h to drm_mode.h
>  - Changed define prefix from DRM_ to DRM_MODE_PROP_ 
>  - Updated uses of the defines to the new prefix
>  - Removed include from drm_rect.c
>  - Stopped using the BIT() macro 
> 
>  drivers/gpu/drm/arm/malidp_drv.h|  2 +-
>  drivers/gpu/drm/arm/malidp_planes.c | 18 -
>  drivers/gpu/drm/armada/armada_overlay.c |  2 +-
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 20 +-
>  drivers/gpu/drm/drm_atomic.c|  2 +-
>  drivers/gpu/drm/drm_atomic_helper.c |  2 +-
>  drivers/gpu/drm/drm_blend.c | 43 ++---
>  drivers/gpu/drm/drm_fb_helper.c |  4 +-
>  drivers/gpu/drm/drm_plane_helper.c  |  2 +-
>  drivers/gpu/drm/drm_rect.c  | 36 +-
>  drivers/gpu/drm/i915/i915_debugfs.c | 14 +++
>  drivers/gpu/drm/i915/intel_atomic_plane.c   |  6 +--
>  drivers/gpu/drm/i915/intel_display.c| 50 
> -
>  drivers/gpu/drm/i915/intel_fbc.c|  2 +-
>  drivers/gpu/drm/i915/intel_fbdev.c  |  2 +-
>  drivers/gpu/drm/i915/intel_sprite.c | 20 +-
>  drivers/gpu/drm/imx/ipuv3-plane.c   |  2 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   | 30 +++
>  drivers/gpu/drm/nouveau/nv50_display.c  |  2 +-
>  drivers/gpu/drm/omapdrm/omap_drv.c  |  4 +-
>  drivers/gpu/drm/omapdrm/omap_fb.c   | 18 -
>  drivers/gpu/drm/omapdrm/omap_plane.c| 16 
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  4 +-
>  include/drm/drm_blend.h | 21 +--
>  include/uapi/drm/drm_mode.h | 49 +++-
>  25 files changed, 201 insertions(+), 170 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.h 
> b/drivers/gpu/drm/arm/malidp_drv.h
> index 040311ffcaec..2e2033140efc 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.h
> +++ b/drivers/gpu/drm/arm/malidp_drv.h
> @@ -65,6 +65,6 @@ void malidp_de_planes_destroy(struct drm_device *drm);
>  int malidp_crtc_init(struct drm_device *drm);
>  
>  /* often used combination of rotational bits */
> -#define MALIDP_ROTATED_MASK  (DRM_ROTATE_90 | DRM_ROTATE_270)
> +#define MALIDP_ROTATED_MASK  (DRM_MODE_ROTATE_90 | DRM_MODE_ROTATE_270)
>  
>  #endif  /* __MALIDP_DRV_H__ */
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 814fda23cead..063a8d2b0be3 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -80,7 +80,7 @@ static void malidp_plane_reset(struct drm_plane *plane)
>   state = kzalloc(sizeof(*state), GFP_KERNEL);
>   if (state) {
>   state->base.plane = plane;
> - state->base.rotation = DRM_ROTATE_0;
> + state->base.rotation = DRM_MODE_ROTATE_0;
>   plane->state = >base;
>   }
>  }
> @@ -221,7 +221,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
>   return ret;
>  
>   /* packed RGB888 / BGR888 can't be rotated or flipped */
> - if (state->rotation != DRM_ROTATE_0 &&
> + if (state->rotation != DRM_MODE_ROTATE_0 &&
>   (fb->format->format == DRM_FORMAT_RGB888 ||
>fb->format->format == DRM_FORMAT_BGR888))
>   return -EINVAL;
> @@ -315,12 +315,12 @@ static void malidp_de_plane_update(struct drm_plane 
> *plane,
>   val &= ~LAYER_ROT_MASK;
>  
>   /* setup the rotation and axis flip bits */
> - if (plane->state->rotation & DRM_ROTATE_MASK)
> - val |= ilog2(plane->state->rotation & DRM_ROTATE_MASK) <<
> + if (plane->state->rotation & DRM_MODE_

Re: [Linux-graphics-maintainer] No mouse cursor since 36cc79bc9077319c04bd3b132edcacaa9a0d9f2b

[Sinclair Yeh]

Hi,

On Wed, May 10, 2017 at 12:31:39PM +0200, m...@ox.io wrote:
> 
> > Thomas Hellstrom hat am 10. Mai 2017 um 10:35 geschrieben:
> > 
> > Hi,
> > 
> > Thanks for reporting.
> 
> I would have reported earlier if it had not taken 3 days on the vm to bisect.
> 
> > I think there is a fix for this either in preparation or queued for
> > submission. Sinclair (CC'd) should know more.
> 
> If you point me to a patch I can test it.

please give this patch a try:

https://cgit.freedesktop.org/mesa/vmwgfx/commit/?id=324722b1e1582d45e865dcd2233a17edcfbd1638

If it doesn't work, then please send me the following:
1. dmesg from the guest
2. vmware.log from the host
3. .vmx file for your VM

thanks,

Sinclair

> 
> > Thanks,
> > Thomas
> 
> Mark
> 
> > 
> > On 05/10/2017 09:17 AM, m.t wrote:
> > > Hi,
> > > I don't have a mouse cursor in my virtual machine (vmware workstation 
> > > 12.5.5 
> > > build-5234757) with latest master from 
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_=DwICAg=uilaK90D4TOVoH58JNXRgQ=j2ey7nuAQ5d6NbMmCOnRsTIJfmv7blo3UCKagbsM9o2-No8JdlhkKK3ty481ErVu=DWnNRbcrxMhc78PIvembLdV3OsJi3vPwcdG03kqVpJo=mc7-KF2t4BktXs11MShGZBf9bzgxumqhmVQ0ocAIS0k=
> > >  
> > > kernel/git/torvalds/linux.git
> > >
> > > git bisect led me to 36cc79bc9077319c04bd3b132edcacaa9a0d9f2b as culprit.
> > >
> > > Regards 
> > > Mark
> > > ___
> > > Sent to linux-graphics-maintai...@vmware.com
> > 
> >

Re: [Linux-graphics-maintainer] No mouse cursor since 36cc79bc9077319c04bd3b132edcacaa9a0d9f2b

[Sinclair Yeh]

Hi,

On Wed, May 10, 2017 at 12:31:39PM +0200, m...@ox.io wrote:
> 
> > Thomas Hellstrom hat am 10. Mai 2017 um 10:35 geschrieben:
> > 
> > Hi,
> > 
> > Thanks for reporting.
> 
> I would have reported earlier if it had not taken 3 days on the vm to bisect.
> 
> > I think there is a fix for this either in preparation or queued for
> > submission. Sinclair (CC'd) should know more.
> 
> If you point me to a patch I can test it.

please give this patch a try:

https://cgit.freedesktop.org/mesa/vmwgfx/commit/?id=324722b1e1582d45e865dcd2233a17edcfbd1638

If it doesn't work, then please send me the following:
1. dmesg from the guest
2. vmware.log from the host
3. .vmx file for your VM

thanks,

Sinclair

> 
> > Thanks,
> > Thomas
> 
> Mark
> 
> > 
> > On 05/10/2017 09:17 AM, m.t wrote:
> > > Hi,
> > > I don't have a mouse cursor in my virtual machine (vmware workstation 
> > > 12.5.5 
> > > build-5234757) with latest master from 
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_=DwICAg=uilaK90D4TOVoH58JNXRgQ=j2ey7nuAQ5d6NbMmCOnRsTIJfmv7blo3UCKagbsM9o2-No8JdlhkKK3ty481ErVu=DWnNRbcrxMhc78PIvembLdV3OsJi3vPwcdG03kqVpJo=mc7-KF2t4BktXs11MShGZBf9bzgxumqhmVQ0ocAIS0k=
> > >  
> > > kernel/git/torvalds/linux.git
> > >
> > > git bisect led me to 36cc79bc9077319c04bd3b132edcacaa9a0d9f2b as culprit.
> > >
> > > Regards 
> > > Mark
> > > ___
> > > Sent to linux-graphics-maintai...@vmware.com
> > 
> >

Re: [PATCH v2] kernel: drm/vmwgfx: limit the number of mip levels in vmw_gb_surface_define_ioctl()

[Sinclair Yeh]

Thanks Vladis!

Reviewed-by: Sinclair Yeh <s...@vmware.com>

On Thu, Apr 06, 2017 at 02:33:40PM +0200, Vladis Dronov wrote:
> The 'req->mip_levels' parameter in vmw_gb_surface_define_ioctl() is
> a user-controlled 'uint32_t' value which is used as a loop count limit.
> This can lead to a kernel lockup and DoS. Add check for 'req->mip_levels'.
> 
> References:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1437431=DwIBAg=uilaK90D4TOVoH58JNXRgQ=HaJ2a6NYExoV0cntAYcoqA=D9ZabTkAbhTqB-puuJ1a4SnWKUIGw0oXestkhJG6dCQ=6PZxBQ8MQjy-uc5pd6vyZg3D5yrG0jlSPi5pPE0oFK4=
>  
> Signed-off-by: Vladis Dronov <vdro...@redhat.com>
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index b445ce9..e0d7ff9 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -1281,6 +1281,9 @@ int vmw_gb_surface_define_ioctl(struct drm_device *dev, 
> void *data,
>   if (req->multisample_count != 0)
>   return -EINVAL;
>  
> + if (req->mip_levels > DRM_VMW_MAX_MIP_LEVELS)
> + return -EINVAL;
> +
>   if (unlikely(vmw_user_surface_size == 0))
>   vmw_user_surface_size = ttm_round_pot(sizeof(*user_srf)) +
>   128;
> -- 
> 2.9.3
> 

Re: [PATCH v2] kernel: drm/vmwgfx: limit the number of mip levels in vmw_gb_surface_define_ioctl()

[Sinclair Yeh]

Thanks Vladis!

Reviewed-by: Sinclair Yeh 

On Thu, Apr 06, 2017 at 02:33:40PM +0200, Vladis Dronov wrote:
> The 'req->mip_levels' parameter in vmw_gb_surface_define_ioctl() is
> a user-controlled 'uint32_t' value which is used as a loop count limit.
> This can lead to a kernel lockup and DoS. Add check for 'req->mip_levels'.
> 
> References:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1437431=DwIBAg=uilaK90D4TOVoH58JNXRgQ=HaJ2a6NYExoV0cntAYcoqA=D9ZabTkAbhTqB-puuJ1a4SnWKUIGw0oXestkhJG6dCQ=6PZxBQ8MQjy-uc5pd6vyZg3D5yrG0jlSPi5pPE0oFK4=
>  
> Signed-off-by: Vladis Dronov 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index b445ce9..e0d7ff9 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -1281,6 +1281,9 @@ int vmw_gb_surface_define_ioctl(struct drm_device *dev, 
> void *data,
>   if (req->multisample_count != 0)
>   return -EINVAL;
>  
> + if (req->mip_levels > DRM_VMW_MAX_MIP_LEVELS)
> + return -EINVAL;
> +
>   if (unlikely(vmw_user_surface_size == 0))
>   vmw_user_surface_size = ttm_round_pot(sizeof(*user_srf)) +
>   128;
> -- 
> 2.9.3
> 

Re: [PATCH] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Sinclair Yeh]

Minor nits, otherwise the vmwgfx part,
  Reviewed-by: Sinclair Yeh <s...@vmware.com>

On Tue, Apr 18, 2017 at 06:17:00PM -0600, Logan Gunthorpe wrote:
> Seeing the kunmap_atomic dma_buf_op shares the same name with a macro
s^

> in higmem.h, the former can be aliased if any dma-buf user includes
   h^
> that header.
> 
> I'm personally trying to include highmem.h inside scatterlist.h and this
> breaks the dma-buf code proper.
> 
> Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
> 
> To maintain consistency I've renamed all four of kmap* and kunmap* to be
> map* and unmap*. (Even though only kmap_atomic presently conflicts.)
> 
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_target-2Ddevel_msg15070.html=DwIBAg=uilaK90D4TOVoH58JNXRgQ=HaJ2a6NYExoV0cntAYcoqA=QP_jolGTC4ofBnHRnAs0tFIXHnVWaTT0AdMyCL9SM64=un2hxBL1283iOTtJeJnvyyvtAu1d5Imyh5Q7AzljrfQ=
>  
> 
> Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
> ---
>  drivers/dma-buf/dma-buf.c  | 16 
>  drivers/gpu/drm/armada/armada_gem.c|  8 
>  drivers/gpu/drm/drm_prime.c|  8 
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
>  drivers/gpu/drm/tegra/gem.c|  4 ++--
>  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
>  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
>  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
>  drivers/staging/android/ion/ion.c  |  8 
>  include/linux/dma-buf.h| 22 +++---
>  13 files changed, 55 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 0007b79..7cc2bfe 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
> || !exp_info->ops->map_dma_buf
> || !exp_info->ops->unmap_dma_buf
> || !exp_info->ops->release
> -   || !exp_info->ops->kmap_atomic
> -   || !exp_info->ops->kmap
> +   || !exp_info->ops->map_atomic
> +   || !exp_info->ops->map
> || !exp_info->ops->mmap)) {
>   return ERR_PTR(-EINVAL);
>   }
> @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, 
> unsigned long page_num)
>  {
>   WARN_ON(!dmabuf);
>  
> - return dmabuf->ops->kmap_atomic(dmabuf, page_num);
> + return dmabuf->ops->map_atomic(dmabuf, page_num);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
>  
> @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, 
> unsigned long page_num,
>  {
>   WARN_ON(!dmabuf);
>  
> - if (dmabuf->ops->kunmap_atomic)
> - dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
> + if (dmabuf->ops->unmap_atomic)
> + dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
>  
> @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long 
> page_num)
>  {
>   WARN_ON(!dmabuf);
>  
> - return dmabuf->ops->kmap(dmabuf, page_num);
> + return dmabuf->ops->map(dmabuf, page_num);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kmap);
>  
> @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long 
> page_num,
>  {
>   WARN_ON(!dmabuf);
>  
> - if (dmabuf->ops->kunmap)
> - dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
> + if (dmabuf->ops->unmap)
> + dmabuf->ops->unmap(dmabuf, page_num, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kunmap);
>  
> diff --git a/drivers/gpu/drm/armada/armada_gem.c 
> b/drivers/gpu/drm/armada/armada_gem.c
> index 1597458..d6c2a5d 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -529,10 +529,10 @@ static const struct dma_buf_ops 
> armada_gem_prime_dmabuf_ops = {
>   .map_dma_buf= armada_gem_prime_map_dma_buf,
>   .unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
>   .release= drm_gem_dmabuf_release,
> - .kmap_atomic= armada_gem_dmabuf_no_kmap,
> - 

Re: [PATCH] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Sinclair Yeh]

Minor nits, otherwise the vmwgfx part,
  Reviewed-by: Sinclair Yeh 

On Tue, Apr 18, 2017 at 06:17:00PM -0600, Logan Gunthorpe wrote:
> Seeing the kunmap_atomic dma_buf_op shares the same name with a macro
s^

> in higmem.h, the former can be aliased if any dma-buf user includes
   h^
> that header.
> 
> I'm personally trying to include highmem.h inside scatterlist.h and this
> breaks the dma-buf code proper.
> 
> Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
> 
> To maintain consistency I've renamed all four of kmap* and kunmap* to be
> map* and unmap*. (Even though only kmap_atomic presently conflicts.)
> 
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_target-2Ddevel_msg15070.html=DwIBAg=uilaK90D4TOVoH58JNXRgQ=HaJ2a6NYExoV0cntAYcoqA=QP_jolGTC4ofBnHRnAs0tFIXHnVWaTT0AdMyCL9SM64=un2hxBL1283iOTtJeJnvyyvtAu1d5Imyh5Q7AzljrfQ=
>  
> 
> Signed-off-by: Logan Gunthorpe 
> ---
>  drivers/dma-buf/dma-buf.c  | 16 
>  drivers/gpu/drm/armada/armada_gem.c|  8 
>  drivers/gpu/drm/drm_prime.c|  8 
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
>  drivers/gpu/drm/tegra/gem.c|  4 ++--
>  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
>  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
>  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
>  drivers/staging/android/ion/ion.c  |  8 
>  include/linux/dma-buf.h| 22 +++---
>  13 files changed, 55 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 0007b79..7cc2bfe 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
> || !exp_info->ops->map_dma_buf
> || !exp_info->ops->unmap_dma_buf
> || !exp_info->ops->release
> -   || !exp_info->ops->kmap_atomic
> -   || !exp_info->ops->kmap
> +   || !exp_info->ops->map_atomic
> +   || !exp_info->ops->map
> || !exp_info->ops->mmap)) {
>   return ERR_PTR(-EINVAL);
>   }
> @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, 
> unsigned long page_num)
>  {
>   WARN_ON(!dmabuf);
>  
> - return dmabuf->ops->kmap_atomic(dmabuf, page_num);
> + return dmabuf->ops->map_atomic(dmabuf, page_num);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
>  
> @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, 
> unsigned long page_num,
>  {
>   WARN_ON(!dmabuf);
>  
> - if (dmabuf->ops->kunmap_atomic)
> - dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
> + if (dmabuf->ops->unmap_atomic)
> + dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
>  
> @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long 
> page_num)
>  {
>   WARN_ON(!dmabuf);
>  
> - return dmabuf->ops->kmap(dmabuf, page_num);
> + return dmabuf->ops->map(dmabuf, page_num);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kmap);
>  
> @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long 
> page_num,
>  {
>   WARN_ON(!dmabuf);
>  
> - if (dmabuf->ops->kunmap)
> - dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
> + if (dmabuf->ops->unmap)
> + dmabuf->ops->unmap(dmabuf, page_num, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kunmap);
>  
> diff --git a/drivers/gpu/drm/armada/armada_gem.c 
> b/drivers/gpu/drm/armada/armada_gem.c
> index 1597458..d6c2a5d 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -529,10 +529,10 @@ static const struct dma_buf_ops 
> armada_gem_prime_dmabuf_ops = {
>   .map_dma_buf= armada_gem_prime_map_dma_buf,
>   .unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
>   .release= drm_gem_dmabuf_release,
> - .kmap_atomic= armada_gem_dmabuf_no_kmap,
> - .kunmap_atomic  = armada_gem_dmabuf_no_kunmap,
> 

Re: linux-next: build failure after merge of the drm-misc tree

[Sinclair Yeh]

Thanks for this.   This and "drm/vmwgfx: merge fixup for set_config API change":

Reviewed-by: Sinclair Yeh <s...@vmware.com>

On Mon, Apr 03, 2017 at 01:31:29PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c: In function 'vmw_sou_crtc_page_flip':
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:327:8: error: too few arguments to 
> function 'drm_atomic_helper_page_flip'
>   ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
> ^
> In file included from drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:31:0:
> include/drm/drm_atomic_helper.h:126:5: note: declared here
>  int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
>  ^
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c: In function 'vmw_stdu_crtc_page_flip':
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:508:8: error: too few arguments to 
> function 'drm_atomic_helper_page_flip'
>   ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
> ^
> In file included from drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:32:0:
> include/drm/drm_atomic_helper.h:126:5: note: declared here
>  int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
>  ^
> 
> Caused by commit
> 
>   41292b1fa13a ("drm: Add acquire ctx parameter to ->page_flip(_target)")
> 
> interacting with commits
> 
>   904bb5e5817f ("drm/vmwgfx: Switch over to internal atomic API for STDU")
>   b0119cb9229d ("drm/vmwgfx: Switch over to internal atomic API for SOU and 
> LDU")
> 
> from the drm tree.
> 
> I added this merge fix patch for today:
> 
> From: Stephen Rothwell <s...@canb.auug.org.au>
> Date: Mon, 3 Apr 2017 13:25:55 +1000
> Subject: [PATCH] drm/vmwgfx: merge fixup for page_flip API change
> 
> Signed-off-by: Stephen Rothwell <s...@canb.auug.org.au>
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> index 02b8f2541dca..8d7dc9def7c2 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> @@ -324,7 +324,7 @@ static int vmw_sou_crtc_page_flip(struct drm_crtc *crtc,
>   return -EINVAL;
>  
>   flags &= ~DRM_MODE_PAGE_FLIP_ASYNC;
> - ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
> + ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags, ctx);
>   if (ret) {
>   DRM_ERROR("Page flip error %d.\n", ret);
>   return ret;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> index e59bbcd8b226..bad31bdf09b6 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> @@ -505,7 +505,7 @@ static int vmw_stdu_crtc_page_flip(struct drm_crtc *crtc,
>* don't hand it to the helper.
>*/
>   flags &= ~DRM_MODE_PAGE_FLIP_ASYNC;
> - ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
> + ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags, ctx);
>   if (ret) {
>   DRM_ERROR("Page flip error %d.\n", ret);
>   return ret;
> -- 
> 2.11.0
> 
> -- 
> Cheers,
> Stephen Rothwell

Re: linux-next: build failure after merge of the drm-misc tree

[Sinclair Yeh]

Thanks for this.   This and "drm/vmwgfx: merge fixup for set_config API change":

Reviewed-by: Sinclair Yeh 

On Mon, Apr 03, 2017 at 01:31:29PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c: In function 'vmw_sou_crtc_page_flip':
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:327:8: error: too few arguments to 
> function 'drm_atomic_helper_page_flip'
>   ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
> ^
> In file included from drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:31:0:
> include/drm/drm_atomic_helper.h:126:5: note: declared here
>  int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
>  ^
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c: In function 'vmw_stdu_crtc_page_flip':
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:508:8: error: too few arguments to 
> function 'drm_atomic_helper_page_flip'
>   ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
> ^
> In file included from drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c:32:0:
> include/drm/drm_atomic_helper.h:126:5: note: declared here
>  int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
>  ^
> 
> Caused by commit
> 
>   41292b1fa13a ("drm: Add acquire ctx parameter to ->page_flip(_target)")
> 
> interacting with commits
> 
>   904bb5e5817f ("drm/vmwgfx: Switch over to internal atomic API for STDU")
>   b0119cb9229d ("drm/vmwgfx: Switch over to internal atomic API for SOU and 
> LDU")
> 
> from the drm tree.
> 
> I added this merge fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Mon, 3 Apr 2017 13:25:55 +1000
> Subject: [PATCH] drm/vmwgfx: merge fixup for page_flip API change
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> index 02b8f2541dca..8d7dc9def7c2 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> @@ -324,7 +324,7 @@ static int vmw_sou_crtc_page_flip(struct drm_crtc *crtc,
>   return -EINVAL;
>  
>   flags &= ~DRM_MODE_PAGE_FLIP_ASYNC;
> - ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
> + ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags, ctx);
>   if (ret) {
>   DRM_ERROR("Page flip error %d.\n", ret);
>   return ret;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> index e59bbcd8b226..bad31bdf09b6 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> @@ -505,7 +505,7 @@ static int vmw_stdu_crtc_page_flip(struct drm_crtc *crtc,
>* don't hand it to the helper.
>*/
>   flags &= ~DRM_MODE_PAGE_FLIP_ASYNC;
> - ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags);
> + ret = drm_atomic_helper_page_flip(crtc, new_fb, NULL, flags, ctx);
>   if (ret) {
>   DRM_ERROR("Page flip error %d.\n", ret);
>   return ret;
> -- 
> 2.11.0
> 
> -- 
> Cheers,
> Stephen Rothwell

Re: [PATCH] kernel: drm/vmwgfx: limit the number of mip levels in vmw_gb_surface_define_ioctl()

[Sinclair Yeh]

Hi Vladis,


On Thu, Mar 30, 2017 at 12:27:12PM +0200, Vladis Dronov wrote:
> The 'req->mip_levels' parameter in vmw_gb_surface_define_ioctl() is
> a user-controlled 'uint32_t' value which is used as a loop count limit.
> This can lead to a kernel lockup and DoS. Add check for 'req->mip_levels'.
> 
> References:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1437431=DwIBAg=uilaK90D4TOVoH58JNXRgQ=HaJ2a6NYExoV0cntAYcoqA=5yR87BuuU86aoAjCveInxh6jvgOyumqIHQhTs0xLo38=tWQs7vwNLgD_b2RWMddVtusEKh9FQTIF5rKFOWudslE=
>  
> Signed-off-by: Vladis Dronov 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index b445ce9..b30824b 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -1281,6 +1281,10 @@ int vmw_gb_surface_define_ioctl(struct drm_device 
> *dev, void *data,
>   if (req->multisample_count != 0)
>   return -EINVAL;
>  
> + if (req->mip_levels > DRM_VMW_MAX_SURFACE_FACES *
> + DRM_VMW_MAX_MIP_LEVELS)
> + return -EINVAL;
> +

Here, the check should be "> DRM_VMW_MAX_MIP_LEVELS" because req->mip_levels
is only for one layer.

Also, as long as we can doing a check, I would suggest we check for 0 as
well.

Sinclair

Re: [PATCH] kernel: drm/vmwgfx: limit the number of mip levels in vmw_gb_surface_define_ioctl()

[Sinclair Yeh]

Hi Vladis,


On Thu, Mar 30, 2017 at 12:27:12PM +0200, Vladis Dronov wrote:
> The 'req->mip_levels' parameter in vmw_gb_surface_define_ioctl() is
> a user-controlled 'uint32_t' value which is used as a loop count limit.
> This can lead to a kernel lockup and DoS. Add check for 'req->mip_levels'.
> 
> References:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1437431=DwIBAg=uilaK90D4TOVoH58JNXRgQ=HaJ2a6NYExoV0cntAYcoqA=5yR87BuuU86aoAjCveInxh6jvgOyumqIHQhTs0xLo38=tWQs7vwNLgD_b2RWMddVtusEKh9FQTIF5rKFOWudslE=
>  
> Signed-off-by: Vladis Dronov 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index b445ce9..b30824b 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -1281,6 +1281,10 @@ int vmw_gb_surface_define_ioctl(struct drm_device 
> *dev, void *data,
>   if (req->multisample_count != 0)
>   return -EINVAL;
>  
> + if (req->mip_levels > DRM_VMW_MAX_SURFACE_FACES *
> + DRM_VMW_MAX_MIP_LEVELS)
> + return -EINVAL;
> +

Here, the check should be "> DRM_VMW_MAX_MIP_LEVELS" because req->mip_levels
is only for one layer.

Also, as long as we can doing a check, I would suggest we check for 0 as
well.

Sinclair

Re: [PATCH] drm/vmwgfx: Check check that number of mip levels is above zero in vmw_surface_define_ioctl()

[Sinclair Yeh]

Hi,

thank you for this patch.  Murray McAllister reported this one a couple
of months ago, and this is already in our queue.

Sinclair

On Fri, Mar 24, 2017 at 04:37:10PM +0100, Vladis Dronov wrote:
> In vmw_surface_define_ioctl(), a num_sizes parameter is assigned a
> user-controlled value which is not checked for zero. It is used in
> a call to kmalloc() which returns ZERO_SIZE_PTR. Later ZERO_SIZE_PTR
> is dereferenced which leads to a GPF and possibly to a kernel panic.
> Add the check for zero to avoid this.
> 
> Reference: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1435719=DwIBAg=uilaK90D4TOVoH58JNXRgQ=HaJ2a6NYExoV0cntAYcoqA=OW9cIAAez9eRIxEYMaToDu2szuR_YrfQcOzAH6L8dXo=-3P2pG3n1YW6-8NG6mLC7kyxmx7mMxJmXgY79ZgQeo4=
>  
> Signed-off-by: Vladis Dronov 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index b445ce9..42840cc 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -716,8 +716,8 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void 
> *data,
>   for (i = 0; i < DRM_VMW_MAX_SURFACE_FACES; ++i)
>   num_sizes += req->mip_levels[i];
>  
> - if (num_sizes > DRM_VMW_MAX_SURFACE_FACES *
> - DRM_VMW_MAX_MIP_LEVELS)
> + if (num_sizes <= 0 ||
> + num_sizes > DRM_VMW_MAX_SURFACE_FACES * DRM_VMW_MAX_MIP_LEVELS)
>   return -EINVAL;
>  
>   size = vmw_user_surface_size + 128 +
> -- 
> 2.9.3
> 

Re: [PATCH] drm/vmwgfx: Check check that number of mip levels is above zero in vmw_surface_define_ioctl()

[Sinclair Yeh]

Hi,

thank you for this patch.  Murray McAllister reported this one a couple
of months ago, and this is already in our queue.

Sinclair

On Fri, Mar 24, 2017 at 04:37:10PM +0100, Vladis Dronov wrote:
> In vmw_surface_define_ioctl(), a num_sizes parameter is assigned a
> user-controlled value which is not checked for zero. It is used in
> a call to kmalloc() which returns ZERO_SIZE_PTR. Later ZERO_SIZE_PTR
> is dereferenced which leads to a GPF and possibly to a kernel panic.
> Add the check for zero to avoid this.
> 
> Reference: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1435719=DwIBAg=uilaK90D4TOVoH58JNXRgQ=HaJ2a6NYExoV0cntAYcoqA=OW9cIAAez9eRIxEYMaToDu2szuR_YrfQcOzAH6L8dXo=-3P2pG3n1YW6-8NG6mLC7kyxmx7mMxJmXgY79ZgQeo4=
>  
> Signed-off-by: Vladis Dronov 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index b445ce9..42840cc 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -716,8 +716,8 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void 
> *data,
>   for (i = 0; i < DRM_VMW_MAX_SURFACE_FACES; ++i)
>   num_sizes += req->mip_levels[i];
>  
> - if (num_sizes > DRM_VMW_MAX_SURFACE_FACES *
> - DRM_VMW_MAX_MIP_LEVELS)
> + if (num_sizes <= 0 ||
> + num_sizes > DRM_VMW_MAX_SURFACE_FACES * DRM_VMW_MAX_MIP_LEVELS)
>   return -EINVAL;
>  
>   size = vmw_user_surface_size + 128 +
> -- 
> 2.9.3
> 

Re: [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_

[Sinclair Yeh]

For drm/vmwgfx:  Acked-by: Sinclair Yeh <s...@vmware.com>

On Tue, Feb 28, 2017 at 04:55:54AM -0800, Joe Perches wrote:
> Use a more common logging style.
> 
> Miscellanea:
> 
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
> 
> Signed-off-by: Joe Perches <j...@perches.com>
> ---
>  drivers/gpu/drm/gma500/cdv_intel_lvds.c   |  9 -
>  drivers/gpu/drm/gma500/oaktrail_lvds.c| 18 +-
>  drivers/gpu/drm/gma500/psb_drv.h  |  5 ++---
>  drivers/gpu/drm/gma500/psb_intel_lvds.c   |  7 +++
>  drivers/gpu/drm/i915/i915_sw_fence.c  |  8 
>  drivers/gpu/drm/mgag200/mgag200_mode.c|  2 +-
>  drivers/gpu/drm/msm/msm_drv.c |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_acpi.c|  7 ---
>  drivers/gpu/drm/nouveau/nouveau_vga.c |  4 ++--
>  drivers/gpu/drm/nouveau/nv50_display.c| 22 +++---
>  drivers/gpu/drm/nouveau/nvkm/core/mm.c| 10 +-
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 17 -
>  drivers/gpu/drm/omapdrm/dss/dss.c |  3 +--
>  drivers/gpu/drm/omapdrm/dss/dss.h | 15 ++-
>  drivers/gpu/drm/omapdrm/omap_gem.c|  5 ++---
>  drivers/gpu/drm/r128/r128_cce.c   |  7 +++
>  drivers/gpu/drm/ttm/ttm_bo.c  |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |  6 ++
>  drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  3 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |  4 ++--
>  20 files changed, 72 insertions(+), 84 deletions(-)
> 
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
> b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> index 5efdb7fbb7ee..e64960db3224 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> @@ -284,8 +284,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder 
> *encoder,
>   head) {
>   if (tmp_encoder != encoder
>   && tmp_encoder->crtc == encoder->crtc) {
> - printk(KERN_ERR "Can't enable LVDS and another "
> -"encoder on the same pipe\n");
> + pr_err("Can't enable LVDS and another encoder on the 
> same pipe\n");
>   return false;
>   }
>   }
> @@ -756,13 +755,13 @@ void cdv_intel_lvds_init(struct drm_device *dev,
>  
>  failed_find:
>   mutex_unlock(>mode_config.mutex);
> - printk(KERN_ERR "Failed find\n");
> + pr_err("Failed find\n");
>   psb_intel_i2c_destroy(gma_encoder->ddc_bus);
>  failed_ddc:
> - printk(KERN_ERR "Failed DDC\n");
> + pr_err("Failed DDC\n");
>   psb_intel_i2c_destroy(gma_encoder->i2c_bus);
>  failed_blc_i2c:
> - printk(KERN_ERR "Failed BLC\n");
> + pr_err("Failed BLC\n");
>   drm_encoder_cleanup(encoder);
>   drm_connector_cleanup(connector);
>   kfree(lvds_priv);
> diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c 
> b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> index f7038f12ac76..e6943fef0611 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> @@ -255,15 +255,15 @@ static void oaktrail_lvds_get_configuration_mode(struct 
> drm_device *dev,
>   ((ti->vblank_hi << 8) | ti->vblank_lo);
>   mode->clock = ti->pixel_clock * 10;
>  #if 0
> - printk(KERN_INFO "hdisplay is %d\n", mode->hdisplay);
> - printk(KERN_INFO "vdisplay is %d\n", mode->vdisplay);
> - printk(KERN_INFO "HSS is %d\n", mode->hsync_start);
> - printk(KERN_INFO "HSE is %d\n", mode->hsync_end);
> - printk(KERN_INFO "htotal is %d\n", mode->htotal);
> - printk(KERN_INFO "VSS is %d\n", mode->vsync_start);
> - printk(KERN_INFO "VSE is %d\n", mode->vsync_end);
> - printk(KERN_INFO "vtotal is %d\n", mode->vtotal);
> - printk(KERN_INFO "clock is %d\n", mode->clock);
> + pr_info("hdisplay is %d\n", mode->hdisplay);
> + pr_info("vdisplay is %d\n", mode->vdisplay);
> + pr_info("HSS is %d\n", mode->hsync_start);
> + pr_info("HSE is %d\n", mode->hsync_end);
> + pr_info("htotal is %d\n", mode->htotal);
> + pr_inf

Re: [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_

[Sinclair Yeh]

For drm/vmwgfx:  Acked-by: Sinclair Yeh 

On Tue, Feb 28, 2017 at 04:55:54AM -0800, Joe Perches wrote:
> Use a more common logging style.
> 
> Miscellanea:
> 
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/gpu/drm/gma500/cdv_intel_lvds.c   |  9 -
>  drivers/gpu/drm/gma500/oaktrail_lvds.c| 18 +-
>  drivers/gpu/drm/gma500/psb_drv.h  |  5 ++---
>  drivers/gpu/drm/gma500/psb_intel_lvds.c   |  7 +++
>  drivers/gpu/drm/i915/i915_sw_fence.c  |  8 
>  drivers/gpu/drm/mgag200/mgag200_mode.c|  2 +-
>  drivers/gpu/drm/msm/msm_drv.c |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_acpi.c|  7 ---
>  drivers/gpu/drm/nouveau/nouveau_vga.c |  4 ++--
>  drivers/gpu/drm/nouveau/nv50_display.c| 22 +++---
>  drivers/gpu/drm/nouveau/nvkm/core/mm.c| 10 +-
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 17 -
>  drivers/gpu/drm/omapdrm/dss/dss.c |  3 +--
>  drivers/gpu/drm/omapdrm/dss/dss.h | 15 ++-
>  drivers/gpu/drm/omapdrm/omap_gem.c|  5 ++---
>  drivers/gpu/drm/r128/r128_cce.c   |  7 +++
>  drivers/gpu/drm/ttm/ttm_bo.c  |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |  6 ++
>  drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  3 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |  4 ++--
>  20 files changed, 72 insertions(+), 84 deletions(-)
> 
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
> b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> index 5efdb7fbb7ee..e64960db3224 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> @@ -284,8 +284,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder 
> *encoder,
>   head) {
>   if (tmp_encoder != encoder
>   && tmp_encoder->crtc == encoder->crtc) {
> - printk(KERN_ERR "Can't enable LVDS and another "
> -"encoder on the same pipe\n");
> + pr_err("Can't enable LVDS and another encoder on the 
> same pipe\n");
>   return false;
>   }
>   }
> @@ -756,13 +755,13 @@ void cdv_intel_lvds_init(struct drm_device *dev,
>  
>  failed_find:
>   mutex_unlock(>mode_config.mutex);
> - printk(KERN_ERR "Failed find\n");
> + pr_err("Failed find\n");
>   psb_intel_i2c_destroy(gma_encoder->ddc_bus);
>  failed_ddc:
> - printk(KERN_ERR "Failed DDC\n");
> + pr_err("Failed DDC\n");
>   psb_intel_i2c_destroy(gma_encoder->i2c_bus);
>  failed_blc_i2c:
> - printk(KERN_ERR "Failed BLC\n");
> + pr_err("Failed BLC\n");
>   drm_encoder_cleanup(encoder);
>   drm_connector_cleanup(connector);
>   kfree(lvds_priv);
> diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c 
> b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> index f7038f12ac76..e6943fef0611 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> @@ -255,15 +255,15 @@ static void oaktrail_lvds_get_configuration_mode(struct 
> drm_device *dev,
>   ((ti->vblank_hi << 8) | ti->vblank_lo);
>   mode->clock = ti->pixel_clock * 10;
>  #if 0
> - printk(KERN_INFO "hdisplay is %d\n", mode->hdisplay);
> - printk(KERN_INFO "vdisplay is %d\n", mode->vdisplay);
> - printk(KERN_INFO "HSS is %d\n", mode->hsync_start);
> - printk(KERN_INFO "HSE is %d\n", mode->hsync_end);
> - printk(KERN_INFO "htotal is %d\n", mode->htotal);
> - printk(KERN_INFO "VSS is %d\n", mode->vsync_start);
> - printk(KERN_INFO "VSE is %d\n", mode->vsync_end);
> - printk(KERN_INFO "vtotal is %d\n", mode->vtotal);
> - printk(KERN_INFO "clock is %d\n", mode->clock);
> + pr_info("hdisplay is %d\n", mode->hdisplay);
> + pr_info("vdisplay is %d\n", mode->vdisplay);
> + pr_info("HSS is %d\n", mode->hsync_start);
> + pr_info("HSE is %d\n", mode->hsync_end);
> + pr_info("htotal is %d\n", mode->htotal);
> + pr_info("VSS 

Re: [PATCH v2] Revert "drm/vmwgfx: Replace numeric parameter like 0444 with macro"

[Sinclair Yeh]

On Fri, Feb 24, 2017 at 11:06:03AM -0800, Sinclair Yeh wrote:
> Hi Oyvind,
> 
> Thanks for looking at this.
> 
> At this moment, I don't really see a benefit one way or anther, so
> I am going to stick with the macro version for now, changing the one
> remaining module_param_named() you mentioned to using the macros to
> keep things consistent.
> 
> If one day we have a paramter with a long ORing of the macros, then
> we can revisit this decision.

Actually, now that I see checkpatch.pl has been modified to prefer
octal permissions, I think your suggestion is better.  So I'll
just take your patch instead.

thanks!

Sinclair



> 
> Sinclair
> 
> On Sat, Feb 04, 2017 at 07:17:27PM +0100, Øyvind A. Holm wrote:
> > This reverts commit 2d8e60e8b0742b7a5cddc806fe38bb81ee876c33.
> > 
> > The commit belongs to the series of 1285 patches sent to LKML on
> > 2016-08-02, it changes the representation of file permissions from the
> > octal value "0600" to "S_IRUSR | S_IWUSR".
> > 
> > The general consensus was that the changes does not increase
> > readability, quite the opposite; 0600 is easier to parse mentally than
> > S_IRUSR | S_IWUSR.
> > 
> > It also causes argument inconsistency, due to commit 04319d89fbec
> > ("drm/vmwgfx: Add an option to change assumed FB bpp") that added
> > another call to module_param_named() where the permissions are written
> > as 0600.
> > 
> > Signed-off-by: Øyvind A. Holm <su...@sunbase.org>
> > ---
> > This is a resend of the patch originally sent on 2017-01-16. The only
> > difference from v1 is an improved commit message with some more details.
> > 
> >  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > index 18061a4bc2f2..e8ae3dc476d1 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > @@ -241,15 +241,15 @@ static int vmwgfx_pm_notifier(struct notifier_block 
> > *nb, unsigned long val,
> >   void *ptr);
> >  
> >  MODULE_PARM_DESC(enable_fbdev, "Enable vmwgfx fbdev");
> > -module_param_named(enable_fbdev, enable_fbdev, int, S_IRUSR | S_IWUSR);
> > +module_param_named(enable_fbdev, enable_fbdev, int, 0600);
> >  MODULE_PARM_DESC(force_dma_api, "Force using the DMA API for TTM pages");
> > -module_param_named(force_dma_api, vmw_force_iommu, int, S_IRUSR | S_IWUSR);
> > +module_param_named(force_dma_api, vmw_force_iommu, int, 0600);
> >  MODULE_PARM_DESC(restrict_iommu, "Try to limit IOMMU usage for TTM pages");
> > -module_param_named(restrict_iommu, vmw_restrict_iommu, int, S_IRUSR | 
> > S_IWUSR);
> > +module_param_named(restrict_iommu, vmw_restrict_iommu, int, 0600);
> >  MODULE_PARM_DESC(force_coherent, "Force coherent TTM pages");
> > -module_param_named(force_coherent, vmw_force_coherent, int, S_IRUSR | 
> > S_IWUSR);
> > +module_param_named(force_coherent, vmw_force_coherent, int, 0600);
> >  MODULE_PARM_DESC(restrict_dma_mask, "Restrict DMA mask to 44 bits with 
> > IOMMU");
> > -module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, S_IRUSR 
> > | S_IWUSR);
> > +module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, 0600);
> >  MODULE_PARM_DESC(assume_16bpp, "Assume 16-bpp when filtering modes");
> >  module_param_named(assume_16bpp, vmw_assume_16bpp, int, 0600);
> >  
> > -- 
> > 2.12.0.rc0
> > 

Re: [PATCH v2] Revert "drm/vmwgfx: Replace numeric parameter like 0444 with macro"

[Sinclair Yeh]

On Fri, Feb 24, 2017 at 11:06:03AM -0800, Sinclair Yeh wrote:
> Hi Oyvind,
> 
> Thanks for looking at this.
> 
> At this moment, I don't really see a benefit one way or anther, so
> I am going to stick with the macro version for now, changing the one
> remaining module_param_named() you mentioned to using the macros to
> keep things consistent.
> 
> If one day we have a paramter with a long ORing of the macros, then
> we can revisit this decision.

Actually, now that I see checkpatch.pl has been modified to prefer
octal permissions, I think your suggestion is better.  So I'll
just take your patch instead.

thanks!

Sinclair



> 
> Sinclair
> 
> On Sat, Feb 04, 2017 at 07:17:27PM +0100, Øyvind A. Holm wrote:
> > This reverts commit 2d8e60e8b0742b7a5cddc806fe38bb81ee876c33.
> > 
> > The commit belongs to the series of 1285 patches sent to LKML on
> > 2016-08-02, it changes the representation of file permissions from the
> > octal value "0600" to "S_IRUSR | S_IWUSR".
> > 
> > The general consensus was that the changes does not increase
> > readability, quite the opposite; 0600 is easier to parse mentally than
> > S_IRUSR | S_IWUSR.
> > 
> > It also causes argument inconsistency, due to commit 04319d89fbec
> > ("drm/vmwgfx: Add an option to change assumed FB bpp") that added
> > another call to module_param_named() where the permissions are written
> > as 0600.
> > 
> > Signed-off-by: Øyvind A. Holm 
> > ---
> > This is a resend of the patch originally sent on 2017-01-16. The only
> > difference from v1 is an improved commit message with some more details.
> > 
> >  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > index 18061a4bc2f2..e8ae3dc476d1 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > @@ -241,15 +241,15 @@ static int vmwgfx_pm_notifier(struct notifier_block 
> > *nb, unsigned long val,
> >   void *ptr);
> >  
> >  MODULE_PARM_DESC(enable_fbdev, "Enable vmwgfx fbdev");
> > -module_param_named(enable_fbdev, enable_fbdev, int, S_IRUSR | S_IWUSR);
> > +module_param_named(enable_fbdev, enable_fbdev, int, 0600);
> >  MODULE_PARM_DESC(force_dma_api, "Force using the DMA API for TTM pages");
> > -module_param_named(force_dma_api, vmw_force_iommu, int, S_IRUSR | S_IWUSR);
> > +module_param_named(force_dma_api, vmw_force_iommu, int, 0600);
> >  MODULE_PARM_DESC(restrict_iommu, "Try to limit IOMMU usage for TTM pages");
> > -module_param_named(restrict_iommu, vmw_restrict_iommu, int, S_IRUSR | 
> > S_IWUSR);
> > +module_param_named(restrict_iommu, vmw_restrict_iommu, int, 0600);
> >  MODULE_PARM_DESC(force_coherent, "Force coherent TTM pages");
> > -module_param_named(force_coherent, vmw_force_coherent, int, S_IRUSR | 
> > S_IWUSR);
> > +module_param_named(force_coherent, vmw_force_coherent, int, 0600);
> >  MODULE_PARM_DESC(restrict_dma_mask, "Restrict DMA mask to 44 bits with 
> > IOMMU");
> > -module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, S_IRUSR 
> > | S_IWUSR);
> > +module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, 0600);
> >  MODULE_PARM_DESC(assume_16bpp, "Assume 16-bpp when filtering modes");
> >  module_param_named(assume_16bpp, vmw_assume_16bpp, int, 0600);
> >  
> > -- 
> > 2.12.0.rc0
> > 

Re: [PATCH v2] Revert "drm/vmwgfx: Replace numeric parameter like 0444 with macro"

[Sinclair Yeh]

Hi Oyvind,

Thanks for looking at this.

At this moment, I don't really see a benefit one way or anther, so
I am going to stick with the macro version for now, changing the one
remaining module_param_named() you mentioned to using the macros to
keep things consistent.

If one day we have a paramter with a long ORing of the macros, then
we can revisit this decision.

Sinclair

On Sat, Feb 04, 2017 at 07:17:27PM +0100, Øyvind A. Holm wrote:
> This reverts commit 2d8e60e8b0742b7a5cddc806fe38bb81ee876c33.
> 
> The commit belongs to the series of 1285 patches sent to LKML on
> 2016-08-02, it changes the representation of file permissions from the
> octal value "0600" to "S_IRUSR | S_IWUSR".
> 
> The general consensus was that the changes does not increase
> readability, quite the opposite; 0600 is easier to parse mentally than
> S_IRUSR | S_IWUSR.
> 
> It also causes argument inconsistency, due to commit 04319d89fbec
> ("drm/vmwgfx: Add an option to change assumed FB bpp") that added
> another call to module_param_named() where the permissions are written
> as 0600.
> 
> Signed-off-by: Øyvind A. Holm 
> ---
> This is a resend of the patch originally sent on 2017-01-16. The only
> difference from v1 is an improved commit message with some more details.
> 
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 18061a4bc2f2..e8ae3dc476d1 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -241,15 +241,15 @@ static int vmwgfx_pm_notifier(struct notifier_block 
> *nb, unsigned long val,
> void *ptr);
>  
>  MODULE_PARM_DESC(enable_fbdev, "Enable vmwgfx fbdev");
> -module_param_named(enable_fbdev, enable_fbdev, int, S_IRUSR | S_IWUSR);
> +module_param_named(enable_fbdev, enable_fbdev, int, 0600);
>  MODULE_PARM_DESC(force_dma_api, "Force using the DMA API for TTM pages");
> -module_param_named(force_dma_api, vmw_force_iommu, int, S_IRUSR | S_IWUSR);
> +module_param_named(force_dma_api, vmw_force_iommu, int, 0600);
>  MODULE_PARM_DESC(restrict_iommu, "Try to limit IOMMU usage for TTM pages");
> -module_param_named(restrict_iommu, vmw_restrict_iommu, int, S_IRUSR | 
> S_IWUSR);
> +module_param_named(restrict_iommu, vmw_restrict_iommu, int, 0600);
>  MODULE_PARM_DESC(force_coherent, "Force coherent TTM pages");
> -module_param_named(force_coherent, vmw_force_coherent, int, S_IRUSR | 
> S_IWUSR);
> +module_param_named(force_coherent, vmw_force_coherent, int, 0600);
>  MODULE_PARM_DESC(restrict_dma_mask, "Restrict DMA mask to 44 bits with 
> IOMMU");
> -module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, S_IRUSR | 
> S_IWUSR);
> +module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, 0600);
>  MODULE_PARM_DESC(assume_16bpp, "Assume 16-bpp when filtering modes");
>  module_param_named(assume_16bpp, vmw_assume_16bpp, int, 0600);
>  
> -- 
> 2.12.0.rc0
> 

Re: [PATCH v2] Revert "drm/vmwgfx: Replace numeric parameter like 0444 with macro"

[Sinclair Yeh]

Hi Oyvind,

Thanks for looking at this.

At this moment, I don't really see a benefit one way or anther, so
I am going to stick with the macro version for now, changing the one
remaining module_param_named() you mentioned to using the macros to
keep things consistent.

If one day we have a paramter with a long ORing of the macros, then
we can revisit this decision.

Sinclair

On Sat, Feb 04, 2017 at 07:17:27PM +0100, Øyvind A. Holm wrote:
> This reverts commit 2d8e60e8b0742b7a5cddc806fe38bb81ee876c33.
> 
> The commit belongs to the series of 1285 patches sent to LKML on
> 2016-08-02, it changes the representation of file permissions from the
> octal value "0600" to "S_IRUSR | S_IWUSR".
> 
> The general consensus was that the changes does not increase
> readability, quite the opposite; 0600 is easier to parse mentally than
> S_IRUSR | S_IWUSR.
> 
> It also causes argument inconsistency, due to commit 04319d89fbec
> ("drm/vmwgfx: Add an option to change assumed FB bpp") that added
> another call to module_param_named() where the permissions are written
> as 0600.
> 
> Signed-off-by: Øyvind A. Holm 
> ---
> This is a resend of the patch originally sent on 2017-01-16. The only
> difference from v1 is an improved commit message with some more details.
> 
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 18061a4bc2f2..e8ae3dc476d1 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -241,15 +241,15 @@ static int vmwgfx_pm_notifier(struct notifier_block 
> *nb, unsigned long val,
> void *ptr);
>  
>  MODULE_PARM_DESC(enable_fbdev, "Enable vmwgfx fbdev");
> -module_param_named(enable_fbdev, enable_fbdev, int, S_IRUSR | S_IWUSR);
> +module_param_named(enable_fbdev, enable_fbdev, int, 0600);
>  MODULE_PARM_DESC(force_dma_api, "Force using the DMA API for TTM pages");
> -module_param_named(force_dma_api, vmw_force_iommu, int, S_IRUSR | S_IWUSR);
> +module_param_named(force_dma_api, vmw_force_iommu, int, 0600);
>  MODULE_PARM_DESC(restrict_iommu, "Try to limit IOMMU usage for TTM pages");
> -module_param_named(restrict_iommu, vmw_restrict_iommu, int, S_IRUSR | 
> S_IWUSR);
> +module_param_named(restrict_iommu, vmw_restrict_iommu, int, 0600);
>  MODULE_PARM_DESC(force_coherent, "Force coherent TTM pages");
> -module_param_named(force_coherent, vmw_force_coherent, int, S_IRUSR | 
> S_IWUSR);
> +module_param_named(force_coherent, vmw_force_coherent, int, 0600);
>  MODULE_PARM_DESC(restrict_dma_mask, "Restrict DMA mask to 44 bits with 
> IOMMU");
> -module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, S_IRUSR | 
> S_IWUSR);
> +module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, 0600);
>  MODULE_PARM_DESC(assume_16bpp, "Assume 16-bpp when filtering modes");
>  module_param_named(assume_16bpp, vmw_assume_16bpp, int, 0600);
>  
> -- 
> 2.12.0.rc0
> 

Re: [PATCH] drm/ttm: Make sure BOs being swapped out are cacheable

[Sinclair Yeh]

On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote:
> Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom:
> >On 01/25/2017 09:21 AM, Michel Dänzer wrote:
> >>From: Michel Dänzer <michel.daen...@amd.com>
> >>
> >>The current caching state may not be tt_cached, even though the
> >>placement contains TTM_PL_FLAG_CACHED, because placement can contain
> >>multiple caching flags. Trying to swap out such a BO would trip up the
> >>
> >>BUG_ON(ttm->caching_state != tt_cached);
> >>
> >>in ttm_tt_swapout.
> >>
> >>Cc: sta...@vger.kernel.org
> >>Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
> >Reviewed-by: Thomas Hellstrom <thellst...@vmware.com>
> 
> Reviewed-by: Christian König <christian.koe...@amd.com>.

Reviewed-by: Sinclair Yeh <s...@vmware.com>

> 
> >
> >>---
> >>  drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> >>index d5063618efa7..86e3b233b722 100644
> >>--- a/drivers/gpu/drm/ttm/ttm_bo.c
> >>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
> >>@@ -1670,7 +1670,6 @@ static int ttm_bo_swapout(struct ttm_mem_shrink 
> >>*shrink)
> >>struct ttm_buffer_object *bo;
> >>int ret = -EBUSY;
> >>int put_count;
> >>-   uint32_t swap_placement = (TTM_PL_FLAG_CACHED | TTM_PL_FLAG_SYSTEM);
> >>spin_lock(>lru_lock);
> >>list_for_each_entry(bo, >swap_lru, swap) {
> >>@@ -1701,7 +1700,8 @@ static int ttm_bo_swapout(struct ttm_mem_shrink 
> >>*shrink)
> >> * Move to system cached
> >> */
> >>-   if ((bo->mem.placement & swap_placement) != swap_placement) {
> >>+   if (bo->mem.mem_type != TTM_PL_SYSTEM ||
> >>+   bo->ttm->caching_state != tt_cached) {
> >>struct ttm_mem_reg evict_mem;
> >>evict_mem = bo->mem;
> >
> 

Re: [PATCH] drm/ttm: Make sure BOs being swapped out are cacheable

[Sinclair Yeh]

On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote:
> Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom:
> >On 01/25/2017 09:21 AM, Michel Dänzer wrote:
> >>From: Michel Dänzer 
> >>
> >>The current caching state may not be tt_cached, even though the
> >>placement contains TTM_PL_FLAG_CACHED, because placement can contain
> >>multiple caching flags. Trying to swap out such a BO would trip up the
> >>
> >>BUG_ON(ttm->caching_state != tt_cached);
> >>
> >>in ttm_tt_swapout.
> >>
> >>Cc: sta...@vger.kernel.org
> >>Signed-off-by: Michel Dänzer 
> >Reviewed-by: Thomas Hellstrom 
> 
> Reviewed-by: Christian König .

Reviewed-by: Sinclair Yeh 

> 
> >
> >>---
> >>  drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> >>index d5063618efa7..86e3b233b722 100644
> >>--- a/drivers/gpu/drm/ttm/ttm_bo.c
> >>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
> >>@@ -1670,7 +1670,6 @@ static int ttm_bo_swapout(struct ttm_mem_shrink 
> >>*shrink)
> >>struct ttm_buffer_object *bo;
> >>int ret = -EBUSY;
> >>int put_count;
> >>-   uint32_t swap_placement = (TTM_PL_FLAG_CACHED | TTM_PL_FLAG_SYSTEM);
> >>spin_lock(>lru_lock);
> >>list_for_each_entry(bo, >swap_lru, swap) {
> >>@@ -1701,7 +1700,8 @@ static int ttm_bo_swapout(struct ttm_mem_shrink 
> >>*shrink)
> >> * Move to system cached
> >> */
> >>-   if ((bo->mem.placement & swap_placement) != swap_placement) {
> >>+   if (bo->mem.mem_type != TTM_PL_SYSTEM ||
> >>+   bo->ttm->caching_state != tt_cached) {
> >>struct ttm_mem_reg evict_mem;
> >>evict_mem = bo->mem;
> >
> 

Re: [PATCH] drm/vmwgfx: use designated initializers

[Sinclair Yeh]

Reviewed-by: Sinclair Yeh <s...@vmware.com>

thanks!

On Fri, Dec 16, 2016 at 05:04:02PM -0800, Kees Cook wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.
> 
> Signed-off-by: Kees Cook <keesc...@chromium.org>
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> index 170b61be1e4e..fec7348cea2c 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> @@ -164,9 +164,9 @@ static void vmw_gmrid_man_debug(struct 
> ttm_mem_type_manager *man,
>  }
>  
>  const struct ttm_mem_type_manager_func vmw_gmrid_manager_func = {
> - vmw_gmrid_man_init,
> - vmw_gmrid_man_takedown,
> - vmw_gmrid_man_get_node,
> - vmw_gmrid_man_put_node,
> - vmw_gmrid_man_debug
> + .init = vmw_gmrid_man_init,
> + .takedown = vmw_gmrid_man_takedown,
> + .get_node = vmw_gmrid_man_get_node,
> + .put_node = vmw_gmrid_man_put_node,
> + .debug = vmw_gmrid_man_debug
>  };
> -- 
> 2.7.4
> 
> 
> -- 
> Kees Cook
> Nexus Security

Re: [PATCH] drm/vmwgfx: use designated initializers

[Sinclair Yeh]

Reviewed-by: Sinclair Yeh 

thanks!

On Fri, Dec 16, 2016 at 05:04:02PM -0800, Kees Cook wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.
> 
> Signed-off-by: Kees Cook 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> index 170b61be1e4e..fec7348cea2c 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> @@ -164,9 +164,9 @@ static void vmw_gmrid_man_debug(struct 
> ttm_mem_type_manager *man,
>  }
>  
>  const struct ttm_mem_type_manager_func vmw_gmrid_manager_func = {
> - vmw_gmrid_man_init,
> - vmw_gmrid_man_takedown,
> - vmw_gmrid_man_get_node,
> - vmw_gmrid_man_put_node,
> - vmw_gmrid_man_debug
> + .init = vmw_gmrid_man_init,
> + .takedown = vmw_gmrid_man_takedown,
> + .get_node = vmw_gmrid_man_get_node,
> + .put_node = vmw_gmrid_man_put_node,
> + .debug = vmw_gmrid_man_debug
>  };
> -- 
> 2.7.4
> 
> 
> -- 
> Kees Cook
> Nexus Security

Re: [PATCH] drm/vmwgfx: Fix handling of errors returned by 'vmw_cotable_alloc()'

[Sinclair Yeh]

Good catch.

Reviewed-by: Sinclair Yeh <s...@vmware.com>

On Tue, Nov 29, 2016 at 07:49:19AM +0100, Christophe JAILLET wrote:
> 'vmw_cotable_alloc()' returns an error pointer on error, not NULL.
> Propagate the error code, instead of returning -ENOMEM unconditionally
> 
> Signed-off-by: Christophe JAILLET <christophe.jail...@wanadoo.fr>
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> index 443d1ed00de7..d1aee9860033 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> @@ -209,8 +209,8 @@ static int vmw_gb_context_init(struct vmw_private 
> *dev_priv,
>   for (i = 0; i < SVGA_COTABLE_DX10_MAX; ++i) {
>   uctx->cotables[i] = vmw_cotable_alloc(dev_priv,
> >res, i);
> - if (unlikely(uctx->cotables[i] == NULL)) {
> - ret = -ENOMEM;
> + if (unlikely(IS_ERR(uctx->cotables[i]))) {
> + ret = PTR_ERR(uctx->cotables[i]);
>   goto out_cotables;
>   }
>   }
> -- 
> 2.9.3
> 

Re: [PATCH] drm/vmwgfx: Fix handling of errors returned by 'vmw_cotable_alloc()'

[Sinclair Yeh]

Good catch.

Reviewed-by: Sinclair Yeh 

On Tue, Nov 29, 2016 at 07:49:19AM +0100, Christophe JAILLET wrote:
> 'vmw_cotable_alloc()' returns an error pointer on error, not NULL.
> Propagate the error code, instead of returning -ENOMEM unconditionally
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> index 443d1ed00de7..d1aee9860033 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> @@ -209,8 +209,8 @@ static int vmw_gb_context_init(struct vmw_private 
> *dev_priv,
>   for (i = 0; i < SVGA_COTABLE_DX10_MAX; ++i) {
>   uctx->cotables[i] = vmw_cotable_alloc(dev_priv,
> >res, i);
> - if (unlikely(uctx->cotables[i] == NULL)) {
> - ret = -ENOMEM;
> + if (unlikely(IS_ERR(uctx->cotables[i]))) {
> + ret = PTR_ERR(uctx->cotables[i]);
>   goto out_cotables;
>   }
>   }
> -- 
> 2.9.3
> 

Re: [PATCH] drm/vmwgfx: avoid gcc-7 parentheses warning

[Sinclair Yeh]

Looks good to me, thanks!
I'll incorporate this into the next pull request.

Reviewed-by: Sinclair Yeh <s...@vmware.com>

On Wed, Nov 16, 2016 at 03:19:31PM +0100, Arnd Bergmann wrote:
> gcc-7 warns about slightly suspicious code in vmw_cmd_invalid:
> 
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c: In function 'vmw_cmd_invalid':
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:522:23: error: the omitted middle 
> operand in ?: will always be 'true', suggest explicit middle operand 
> [-Werror=parentheses]
> 
> The problem is that it is mixing boolean and integer values here.
> I assume that the code actually works correctly, so making it use
> a literal '1' instead of the implied 'true' makes it more readable
> and avoids the warning.
> 
> The code has been in this file since the start, but it could
> make sense to backport this patch to stable to make it build cleanly
> with gcc-7.
> 
> Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index c7b53d987f06..3f343e55972a 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -519,7 +519,7 @@ static int vmw_cmd_invalid(struct vmw_private *dev_priv,
>  struct vmw_sw_context *sw_context,
>  SVGA3dCmdHeader *header)
>  {
> - return capable(CAP_SYS_ADMIN) ? : -EINVAL;
> + return capable(CAP_SYS_ADMIN) ? 1 : -EINVAL;
>  }
>  
>  static int vmw_cmd_ok(struct vmw_private *dev_priv,
> -- 
> 2.9.0
> 

Re: [PATCH] drm/vmwgfx: avoid gcc-7 parentheses warning

[Sinclair Yeh]

Looks good to me, thanks!
I'll incorporate this into the next pull request.

Reviewed-by: Sinclair Yeh 

On Wed, Nov 16, 2016 at 03:19:31PM +0100, Arnd Bergmann wrote:
> gcc-7 warns about slightly suspicious code in vmw_cmd_invalid:
> 
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c: In function 'vmw_cmd_invalid':
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:522:23: error: the omitted middle 
> operand in ?: will always be 'true', suggest explicit middle operand 
> [-Werror=parentheses]
> 
> The problem is that it is mixing boolean and integer values here.
> I assume that the code actually works correctly, so making it use
> a literal '1' instead of the implied 'true' makes it more readable
> and avoids the warning.
> 
> The code has been in this file since the start, but it could
> make sense to backport this patch to stable to make it build cleanly
> with gcc-7.
> 
> Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index c7b53d987f06..3f343e55972a 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -519,7 +519,7 @@ static int vmw_cmd_invalid(struct vmw_private *dev_priv,
>  struct vmw_sw_context *sw_context,
>  SVGA3dCmdHeader *header)
>  {
> - return capable(CAP_SYS_ADMIN) ? : -EINVAL;
> + return capable(CAP_SYS_ADMIN) ? 1 : -EINVAL;
>  }
>  
>  static int vmw_cmd_ok(struct vmw_private *dev_priv,
> -- 
> 2.9.0
> 

Re: [PATCH] drm/vmwgfx : Fix NULL pointer comparison

[Sinclair Yeh]

Thanks!

Reviewed-by: Sinclair Yeh <s...@vmware.com>

On Tue, Nov 08, 2016 at 05:30:31PM +0530, Ravikant Bijendra Sharma wrote:
> From: Ravikant B Sharma <ravikant...@samsung.com>
> 
> Replace direct comparisons to NULL i.e.
> 'x == NULL' with '!x'. As per coding standard.
> 
> Signed-off-by: Ravikant B Sharma <ravikant...@samsung.com>
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c|4 ++--
>  drivers/gpu/drm/vmwgfx/vmwgfx_context.c   |2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c   |2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |6 +++---
>  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c   |4 ++--
>  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |   10 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_mob.c   |6 +++---
>  drivers/gpu/drm/vmwgfx/vmwgfx_msg.c   |6 +++---
>  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |6 +++---
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c  |2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_shader.c|6 +++---
>  12 files changed, 28 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> index 13db8a2..133c8bd 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> @@ -205,7 +205,7 @@ int vmw_cmdbuf_res_add(struct vmw_cmdbuf_res_manager *man,
>   int ret;
>  
>   cres = kzalloc(sizeof(*cres), GFP_KERNEL);
> - if (unlikely(cres == NULL))
> + if (unlikely(!cres))
>   return -ENOMEM;
>  
>   cres->hash.key = user_key | (res_type << 24);
> @@ -291,7 +291,7 @@ struct vmw_cmdbuf_res_manager *
>   int ret;
>  
>   man = kzalloc(sizeof(*man), GFP_KERNEL);
> - if (man == NULL)
> + if (!man)
>   return ERR_PTR(-ENOMEM);
>  
>   man->dev_priv = dev_priv;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> index 443d1ed..1a46b18 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> @@ -776,7 +776,7 @@ static int vmw_context_define(struct drm_device *dev, 
> void *data,
>   }
>  
>   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> - if (unlikely(ctx == NULL)) {
> + if (unlikely(!ctx)) {
>   ttm_mem_global_free(vmw_mem_glob(dev_priv),
>   vmw_user_context_size);
>   ret = -ENOMEM;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
> index 265c81e..8751805 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
> @@ -583,7 +583,7 @@ struct vmw_resource *vmw_cotable_alloc(struct vmw_private 
> *dev_priv,
>   return ERR_PTR(ret);
>  
>   vcotbl = kzalloc(sizeof(*vcotbl), GFP_KERNEL);
> - if (unlikely(vcotbl == NULL)) {
> + if (unlikely(!vcotbl)) {
>   ret = -ENOMEM;
>   goto out_no_alloc;
>   }
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 18061a4..8a269db 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -625,7 +625,7 @@ static int vmw_driver_load(struct drm_device *dev, 
> unsigned long chipset)
>   char host_log[100] = {0};
>  
>   dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
> - if (unlikely(dev_priv == NULL)) {
> + if (unlikely(!dev_priv)) {
>   DRM_ERROR("Failed allocating a device private struct.\n");
>   return -ENOMEM;
>   }
> @@ -1029,7 +1029,7 @@ static int vmw_driver_open(struct drm_device *dev, 
> struct drm_file *file_priv)
>   int ret = -ENOMEM;
>  
>   vmw_fp = kzalloc(sizeof(*vmw_fp), GFP_KERNEL);
> - if (unlikely(vmw_fp == NULL))
> + if (unlikely(!vmw_fp))
>   return ret;
>  
>   vmw_fp->tfile = ttm_object_file_init(dev_priv->tdev, 10);
> @@ -1186,7 +1186,7 @@ static int vmw_master_create(struct drm_device *dev,
>   struct vmw_master *vmaster;
>  
>   vmaster = kzalloc(sizeof(*vmaster), GFP_KERNEL);
> - if (unlikely(vmaster == NULL))
> + if (unlikely(!vmaster))
>   return -ENOMEM;
>  
>   vmw_master_init(vmaster);
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index c7b53d9..2154257 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c

Re: [PATCH] drm/vmwgfx : Fix NULL pointer comparison

[Sinclair Yeh]

Thanks!

Reviewed-by: Sinclair Yeh 

On Tue, Nov 08, 2016 at 05:30:31PM +0530, Ravikant Bijendra Sharma wrote:
> From: Ravikant B Sharma 
> 
> Replace direct comparisons to NULL i.e.
> 'x == NULL' with '!x'. As per coding standard.
> 
> Signed-off-by: Ravikant B Sharma 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c|4 ++--
>  drivers/gpu/drm/vmwgfx/vmwgfx_context.c   |2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c   |2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |6 +++---
>  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c   |4 ++--
>  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |   10 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_mob.c   |6 +++---
>  drivers/gpu/drm/vmwgfx/vmwgfx_msg.c   |6 +++---
>  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |6 +++---
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c  |2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_shader.c|6 +++---
>  12 files changed, 28 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> index 13db8a2..133c8bd 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> @@ -205,7 +205,7 @@ int vmw_cmdbuf_res_add(struct vmw_cmdbuf_res_manager *man,
>   int ret;
>  
>   cres = kzalloc(sizeof(*cres), GFP_KERNEL);
> - if (unlikely(cres == NULL))
> + if (unlikely(!cres))
>   return -ENOMEM;
>  
>   cres->hash.key = user_key | (res_type << 24);
> @@ -291,7 +291,7 @@ struct vmw_cmdbuf_res_manager *
>   int ret;
>  
>   man = kzalloc(sizeof(*man), GFP_KERNEL);
> - if (man == NULL)
> + if (!man)
>   return ERR_PTR(-ENOMEM);
>  
>   man->dev_priv = dev_priv;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> index 443d1ed..1a46b18 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> @@ -776,7 +776,7 @@ static int vmw_context_define(struct drm_device *dev, 
> void *data,
>   }
>  
>   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> - if (unlikely(ctx == NULL)) {
> + if (unlikely(!ctx)) {
>   ttm_mem_global_free(vmw_mem_glob(dev_priv),
>   vmw_user_context_size);
>   ret = -ENOMEM;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
> index 265c81e..8751805 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
> @@ -583,7 +583,7 @@ struct vmw_resource *vmw_cotable_alloc(struct vmw_private 
> *dev_priv,
>   return ERR_PTR(ret);
>  
>   vcotbl = kzalloc(sizeof(*vcotbl), GFP_KERNEL);
> - if (unlikely(vcotbl == NULL)) {
> + if (unlikely(!vcotbl)) {
>   ret = -ENOMEM;
>   goto out_no_alloc;
>   }
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 18061a4..8a269db 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -625,7 +625,7 @@ static int vmw_driver_load(struct drm_device *dev, 
> unsigned long chipset)
>   char host_log[100] = {0};
>  
>   dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
> - if (unlikely(dev_priv == NULL)) {
> + if (unlikely(!dev_priv)) {
>   DRM_ERROR("Failed allocating a device private struct.\n");
>   return -ENOMEM;
>   }
> @@ -1029,7 +1029,7 @@ static int vmw_driver_open(struct drm_device *dev, 
> struct drm_file *file_priv)
>   int ret = -ENOMEM;
>  
>   vmw_fp = kzalloc(sizeof(*vmw_fp), GFP_KERNEL);
> - if (unlikely(vmw_fp == NULL))
> + if (unlikely(!vmw_fp))
>   return ret;
>  
>   vmw_fp->tfile = ttm_object_file_init(dev_priv->tdev, 10);
> @@ -1186,7 +1186,7 @@ static int vmw_master_create(struct drm_device *dev,
>   struct vmw_master *vmaster;
>  
>   vmaster = kzalloc(sizeof(*vmaster), GFP_KERNEL);
> - if (unlikely(vmaster == NULL))
> + if (unlikely(!vmaster))
>   return -ENOMEM;
>  
>   vmw_master_init(vmaster);
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index c7b53d9..2154257 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -264,7 +264,7 @@ static int vmw_resource_val_add(struct vmw_sw_context 
> *

Re: [PATCH v2] drm: move allocation out of drm_get_format_name()

[Sinclair Yeh]

Thomas has already acked the earlier version, but in case you need
it for this one, too.

vmwgfx portion:  Acked-by: Sinclair Yeh <s...@vmware.com>

On Mon, Nov 07, 2016 at 12:48:09AM +, Eric Engestrom wrote:
> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
> 
> drm: make drm_get_format_name thread-safe
> 
> Signed-off-by: Eric Engestrom <e...@engestrom.ch>
> [danvet: Clarify that the returned pointer must be freed with
> kfree().]
> Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> 
> Cc: Rob Clark <robdcl...@gmail.com>
> Cc: Christian König <christian.koe...@amd.com>
> Suggested-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Signed-off-by: Eric Engestrom <e...@engestrom.ch>
> ---
> 
> v2: use single-field struct instead of typedef to let the compiler
> enforce the type (Christian König)
> 
> ---
>  include/drm/drm_fourcc.h| 10 +-
>  drivers/gpu/drm/drm_fourcc.c| 14 +++--
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  7 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  7 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  3 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  7 ++---
>  drivers/gpu/drm/drm_atomic.c|  7 +++--
>  drivers/gpu/drm/drm_crtc.c  |  7 +++--
>  drivers/gpu/drm/drm_framebuffer.c   |  7 +++--
>  drivers/gpu/drm/drm_modeset_helper.c|  7 +++--
>  drivers/gpu/drm/drm_plane.c |  7 +++--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  7 ++---
>  drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
>  drivers/gpu/drm/i915/intel_atomic_plane.c   |  8 ++---
>  drivers/gpu/drm/i915/intel_display.c| 41 
> ++---
>  drivers/gpu/drm/radeon/atombios_crtc.c  | 14 -
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  3 +-
>  17 files changed, 80 insertions(+), 86 deletions(-)
> 
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index dc0aafa..4b03ca0 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -45,6 +45,14 @@ struct drm_format_info {
>   u8 vsub;
>  };
>  
> +/**
> + * struct drm_format_name_buf - name of a DRM format
> + * @str: string buffer containing the format name
> + */
> +struct drm_format_name_buf {
> + char str[32];
> +};
> +
>  const struct drm_format_info *__drm_format_info(u32 format);
>  const struct drm_format_info *drm_format_info(u32 format);
>  uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
> @@ -54,6 +62,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
>  int drm_format_vert_chroma_subsampling(uint32_t format);
>  int drm_format_plane_width(int width, uint32_t format, int plane);
>  int drm_format_plane_height(int height, uint32_t format, int plane);
> -char *drm_get_format_name(uint32_t format) __malloc;
> +char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
>  
>  #endif /* __DRM_FOURCC_H__ */
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index cbb8b77..99b0b60 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -79,17 +79,13 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t 
> depth)
>  EXPORT_SYMBOL(drm_mode_legacy_fb_format);
>  
>  /**
> - * drm_get_format_name - return a string for drm fourcc format
> + * drm_get_format_name - fill a string with a drm fourcc format's name
>   * @format: format to compute name of
> + * @buf: caller-supplied buffer
> - *
> - * Note that the buffer returned by this function is owned by the caller
> - * and will need to be freed using kfree().
>   */
> -char *drm_get_format_name(uint32_t format)
> +char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf)
>  {
> - char *buf = kmalloc(32, GFP_KERNEL);
> -
> - snprintf(buf, 32,
> + snprintf(buf->str, sizeof(buf->str),
>"%c%c%c%c %s-endian (0x%08x)",
>printable_char(format & 0xff),
>printable_char((format >> 8) & 0xff),
> @@ -98,7 +94,7 @@ char *drm_get_format_name(uint32_t format)
>format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
>format);
>  
> - return buf;
> + return buf->str;
>  }
>  EXPORT_SYMBOL(drm_get_format_name);
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 199d3f7..2924cdd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce

Re: [PATCH v2] drm: move allocation out of drm_get_format_name()

[Sinclair Yeh]

Thomas has already acked the earlier version, but in case you need
it for this one, too.

vmwgfx portion:  Acked-by: Sinclair Yeh 

On Mon, Nov 07, 2016 at 12:48:09AM +, Eric Engestrom wrote:
> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
> 
> drm: make drm_get_format_name thread-safe
> 
> Signed-off-by: Eric Engestrom 
> [danvet: Clarify that the returned pointer must be freed with
> kfree().]
> Signed-off-by: Daniel Vetter 
> 
> Cc: Rob Clark 
> Cc: Christian König 
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Eric Engestrom 
> ---
> 
> v2: use single-field struct instead of typedef to let the compiler
> enforce the type (Christian König)
> 
> ---
>  include/drm/drm_fourcc.h| 10 +-
>  drivers/gpu/drm/drm_fourcc.c| 14 +++--
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  7 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  7 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  3 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  7 ++---
>  drivers/gpu/drm/drm_atomic.c|  7 +++--
>  drivers/gpu/drm/drm_crtc.c  |  7 +++--
>  drivers/gpu/drm/drm_framebuffer.c   |  7 +++--
>  drivers/gpu/drm/drm_modeset_helper.c|  7 +++--
>  drivers/gpu/drm/drm_plane.c |  7 +++--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  7 ++---
>  drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
>  drivers/gpu/drm/i915/intel_atomic_plane.c   |  8 ++---
>  drivers/gpu/drm/i915/intel_display.c| 41 
> ++---
>  drivers/gpu/drm/radeon/atombios_crtc.c  | 14 -
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  3 +-
>  17 files changed, 80 insertions(+), 86 deletions(-)
> 
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index dc0aafa..4b03ca0 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -45,6 +45,14 @@ struct drm_format_info {
>   u8 vsub;
>  };
>  
> +/**
> + * struct drm_format_name_buf - name of a DRM format
> + * @str: string buffer containing the format name
> + */
> +struct drm_format_name_buf {
> + char str[32];
> +};
> +
>  const struct drm_format_info *__drm_format_info(u32 format);
>  const struct drm_format_info *drm_format_info(u32 format);
>  uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
> @@ -54,6 +62,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
>  int drm_format_vert_chroma_subsampling(uint32_t format);
>  int drm_format_plane_width(int width, uint32_t format, int plane);
>  int drm_format_plane_height(int height, uint32_t format, int plane);
> -char *drm_get_format_name(uint32_t format) __malloc;
> +char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
>  
>  #endif /* __DRM_FOURCC_H__ */
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index cbb8b77..99b0b60 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -79,17 +79,13 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t 
> depth)
>  EXPORT_SYMBOL(drm_mode_legacy_fb_format);
>  
>  /**
> - * drm_get_format_name - return a string for drm fourcc format
> + * drm_get_format_name - fill a string with a drm fourcc format's name
>   * @format: format to compute name of
> + * @buf: caller-supplied buffer
> - *
> - * Note that the buffer returned by this function is owned by the caller
> - * and will need to be freed using kfree().
>   */
> -char *drm_get_format_name(uint32_t format)
> +char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf)
>  {
> - char *buf = kmalloc(32, GFP_KERNEL);
> -
> - snprintf(buf, 32,
> + snprintf(buf->str, sizeof(buf->str),
>"%c%c%c%c %s-endian (0x%08x)",
>printable_char(format & 0xff),
>printable_char((format >> 8) & 0xff),
> @@ -98,7 +94,7 @@ char *drm_get_format_name(uint32_t format)
>format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
>format);
>  
> - return buf;
> + return buf->str;
>  }
>  EXPORT_SYMBOL(drm_get_format_name);
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 199d3f7..2924cdd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -2032,7 +2032,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
> *crtc,
>   u32 tmp, viewport_w, viewport_h;
&

Re: [PATCH 3/3] drm/vmwgfx: Adjust checks for null pointers in 13 functions

[Sinclair Yeh]

This series looks good to me:  Reviewed-by: Sinclair Yeh <s...@vmware.com>

Thanks!

On Fri, Sep 23, 2016 at 06:39:04PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Fri, 23 Sep 2016 17:53:49 +0200
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> The script "checkpatch.pl" can point information out like the following.
> 
> Comparison to NULL could be written !…
> 
> Thus fix the affected source code places.
> 
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 31 +++
>  1 file changed, 15 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index 15504c6..b445ce9 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -324,7 +324,7 @@ static void vmw_hw_surface_destroy(struct vmw_resource 
> *res)
>   if (res->id != -1) {
>  
>   cmd = vmw_fifo_reserve(dev_priv, vmw_surface_destroy_size());
> - if (unlikely(cmd == NULL)) {
> + if (unlikely(!cmd)) {
>   DRM_ERROR("Failed reserving FIFO space for surface "
> "destruction.\n");
>   return;
> @@ -397,7 +397,7 @@ static int vmw_legacy_srf_create(struct vmw_resource *res)
>  
>   submit_size = vmw_surface_define_size(srf);
>   cmd = vmw_fifo_reserve(dev_priv, submit_size);
> - if (unlikely(cmd == NULL)) {
> + if (unlikely(!cmd)) {
>   DRM_ERROR("Failed reserving FIFO space for surface "
> "creation.\n");
>   ret = -ENOMEM;
> @@ -446,11 +446,10 @@ static int vmw_legacy_srf_dma(struct vmw_resource *res,
>   uint8_t *cmd;
>   struct vmw_private *dev_priv = res->dev_priv;
>  
> - BUG_ON(val_buf->bo == NULL);
> -
> + BUG_ON(!val_buf->bo);
>   submit_size = vmw_surface_dma_size(srf);
>   cmd = vmw_fifo_reserve(dev_priv, submit_size);
> - if (unlikely(cmd == NULL)) {
> + if (unlikely(!cmd)) {
>   DRM_ERROR("Failed reserving FIFO space for surface "
> "DMA.\n");
>   return -ENOMEM;
> @@ -538,7 +537,7 @@ static int vmw_legacy_srf_destroy(struct vmw_resource 
> *res)
>  
>   submit_size = vmw_surface_destroy_size();
>   cmd = vmw_fifo_reserve(dev_priv, submit_size);
> - if (unlikely(cmd == NULL)) {
> + if (unlikely(!cmd)) {
>   DRM_ERROR("Failed reserving FIFO space for surface "
> "eviction.\n");
>   return -ENOMEM;
> @@ -578,7 +577,7 @@ static int vmw_surface_init(struct vmw_private *dev_priv,
>   int ret;
>   struct vmw_resource *res = >res;
>  
> - BUG_ON(res_free == NULL);
> + BUG_ON(!res_free);
>   if (!dev_priv->has_mob)
>   vmw_fifo_resource_inc(dev_priv);
>   ret = vmw_resource_init(dev_priv, res, true, res_free,
> @@ -747,7 +746,7 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void 
> *data,
>   }
>  
>   user_srf = kzalloc(sizeof(*user_srf), GFP_KERNEL);
> - if (unlikely(user_srf == NULL)) {
> + if (unlikely(!user_srf)) {
>   ret = -ENOMEM;
>   goto out_no_user_srf;
>   }
> @@ -772,7 +771,7 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void 
> *data,
>   srf->offsets = kmalloc_array(srf->num_sizes,
>sizeof(*srf->offsets),
>GFP_KERNEL);
> - if (unlikely(srf->offsets == NULL)) {
> + if (unlikely(!srf->offsets)) {
>   ret = -ENOMEM;
>   goto out_no_offsets;
>   }
> @@ -914,7 +913,7 @@ vmw_surface_handle_reference(struct vmw_private *dev_priv,
>  
>   ret = -EINVAL;
>   base = ttm_base_object_lookup_for_ref(dev_priv->tdev, handle);
> - if (unlikely(base == NULL)) {
> + if (unlikely(!base)) {
>   DRM_ERROR("Could not find surface to reference.\n");
>   goto out_no_lookup;
>   }
> @@ -1060,7 +1059,7 @@ static int vmw_gb_surface_create(struct vmw_resource 
> *res)
>  
>   cmd = vmw_fifo_reserve(dev_priv, submit_len);
>   cmd2 = (typeof(cmd2))cmd;
> - if (unlikely(cmd == NULL)) {
> + if (unlikely(!cmd)) {
>   DRM_ERROR("Failed reserving FIFO space for surface "
> 

Re: [PATCH 3/3] drm/vmwgfx: Adjust checks for null pointers in 13 functions

[Sinclair Yeh]

This series looks good to me:  Reviewed-by: Sinclair Yeh 

Thanks!

On Fri, Sep 23, 2016 at 06:39:04PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Fri, 23 Sep 2016 17:53:49 +0200
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> The script "checkpatch.pl" can point information out like the following.
> 
> Comparison to NULL could be written !…
> 
> Thus fix the affected source code places.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 31 +++
>  1 file changed, 15 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index 15504c6..b445ce9 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -324,7 +324,7 @@ static void vmw_hw_surface_destroy(struct vmw_resource 
> *res)
>   if (res->id != -1) {
>  
>   cmd = vmw_fifo_reserve(dev_priv, vmw_surface_destroy_size());
> - if (unlikely(cmd == NULL)) {
> + if (unlikely(!cmd)) {
>   DRM_ERROR("Failed reserving FIFO space for surface "
> "destruction.\n");
>   return;
> @@ -397,7 +397,7 @@ static int vmw_legacy_srf_create(struct vmw_resource *res)
>  
>   submit_size = vmw_surface_define_size(srf);
>   cmd = vmw_fifo_reserve(dev_priv, submit_size);
> - if (unlikely(cmd == NULL)) {
> + if (unlikely(!cmd)) {
>   DRM_ERROR("Failed reserving FIFO space for surface "
> "creation.\n");
>   ret = -ENOMEM;
> @@ -446,11 +446,10 @@ static int vmw_legacy_srf_dma(struct vmw_resource *res,
>   uint8_t *cmd;
>   struct vmw_private *dev_priv = res->dev_priv;
>  
> - BUG_ON(val_buf->bo == NULL);
> -
> + BUG_ON(!val_buf->bo);
>   submit_size = vmw_surface_dma_size(srf);
>   cmd = vmw_fifo_reserve(dev_priv, submit_size);
> - if (unlikely(cmd == NULL)) {
> + if (unlikely(!cmd)) {
>   DRM_ERROR("Failed reserving FIFO space for surface "
> "DMA.\n");
>   return -ENOMEM;
> @@ -538,7 +537,7 @@ static int vmw_legacy_srf_destroy(struct vmw_resource 
> *res)
>  
>   submit_size = vmw_surface_destroy_size();
>   cmd = vmw_fifo_reserve(dev_priv, submit_size);
> - if (unlikely(cmd == NULL)) {
> + if (unlikely(!cmd)) {
>   DRM_ERROR("Failed reserving FIFO space for surface "
> "eviction.\n");
>   return -ENOMEM;
> @@ -578,7 +577,7 @@ static int vmw_surface_init(struct vmw_private *dev_priv,
>   int ret;
>   struct vmw_resource *res = >res;
>  
> - BUG_ON(res_free == NULL);
> + BUG_ON(!res_free);
>   if (!dev_priv->has_mob)
>   vmw_fifo_resource_inc(dev_priv);
>   ret = vmw_resource_init(dev_priv, res, true, res_free,
> @@ -747,7 +746,7 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void 
> *data,
>   }
>  
>   user_srf = kzalloc(sizeof(*user_srf), GFP_KERNEL);
> - if (unlikely(user_srf == NULL)) {
> + if (unlikely(!user_srf)) {
>   ret = -ENOMEM;
>   goto out_no_user_srf;
>   }
> @@ -772,7 +771,7 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void 
> *data,
>   srf->offsets = kmalloc_array(srf->num_sizes,
>sizeof(*srf->offsets),
>GFP_KERNEL);
> - if (unlikely(srf->offsets == NULL)) {
> + if (unlikely(!srf->offsets)) {
>   ret = -ENOMEM;
>   goto out_no_offsets;
>   }
> @@ -914,7 +913,7 @@ vmw_surface_handle_reference(struct vmw_private *dev_priv,
>  
>   ret = -EINVAL;
>   base = ttm_base_object_lookup_for_ref(dev_priv->tdev, handle);
> - if (unlikely(base == NULL)) {
> + if (unlikely(!base)) {
>   DRM_ERROR("Could not find surface to reference.\n");
>   goto out_no_lookup;
>   }
> @@ -1060,7 +1059,7 @@ static int vmw_gb_surface_create(struct vmw_resource 
> *res)
>  
>   cmd = vmw_fifo_reserve(dev_priv, submit_len);
>   cmd2 = (typeof(cmd2))cmd;
> - if (unlikely(cmd == NULL)) {
> + if (unlikely(!cmd)) {
>   DRM_ERROR("Failed reserving FIFO space for surface "
> "creation.\n");
>   ret = -ENOMEM;
> @@ -112

Re: [PATCH v2] usercopy: remove page-spanning test for now

[Sinclair Yeh]

Reviewed-by: Sinclair Yeh <s...@vmware.com>

On Wed, Sep 07, 2016 at 11:08:45AM -0700, Kees Cook wrote:
> A custom allocator without __GFP_COMP that copies to userspace has been
> found in vmw_execbuf_process[1], so this disables the page-span checker
> by placing it behind a CONFIG for future work where such things can be
> tracked down later.
> 
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1373326=CwIBAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=w9Iu3o4zAy-3-s8MFvrNSQ=HmnBFNgZxprKMPy51P5NjJYN3A5FrdjyzaM817eexKU=Htqh5qkhK5mXIdzTCYiqCaZU1R98sOatRFgsoDbGOzw=
>  
> 
> Reported-by: Vinson Lee <v...@freedesktop.org>
> Fixes: f5509cc18daa ("mm: Hardened usercopy")
> Signed-off-by: Kees Cook <keesc...@chromium.org>
> ---
> v2:
> - split logic into separate function entirely, torvalds
> ---
>  mm/usercopy.c| 61 
> 
>  security/Kconfig | 11 ++
>  2 files changed, 46 insertions(+), 26 deletions(-)
> 
> diff --git a/mm/usercopy.c b/mm/usercopy.c
> index a3cc3052f830..089328f2b920 100644
> --- a/mm/usercopy.c
> +++ b/mm/usercopy.c
> @@ -134,31 +134,16 @@ static inline const char *check_bogus_address(const 
> void *ptr, unsigned long n)
>   return NULL;
>  }
>  
> -static inline const char *check_heap_object(const void *ptr, unsigned long n,
> - bool to_user)
> +/* Checks for allocs that are marked in some way as spanning multiple pages. 
> */
> +static inline const char *check_page_span(const void *ptr, unsigned long n,
> +   struct page *page, bool to_user)
>  {
> - struct page *page, *endpage;
> +#ifdef CONFIG_HARDENED_USERCOPY_PAGESPAN
>   const void *end = ptr + n - 1;
> + struct page *endpage;
>   bool is_reserved, is_cma;
>  
>   /*
> -  * Some architectures (arm64) return true for virt_addr_valid() on
> -  * vmalloced addresses. Work around this by checking for vmalloc
> -  * first.
> -  */
> - if (is_vmalloc_addr(ptr))
> - return NULL;
> -
> - if (!virt_addr_valid(ptr))
> - return NULL;
> -
> - page = virt_to_head_page(ptr);
> -
> - /* Check slab allocator for flags and size. */
> - if (PageSlab(page))
> - return __check_heap_object(ptr, n, page);
> -
> - /*
>* Sometimes the kernel data regions are not marked Reserved (see
>* check below). And sometimes [_sdata,_edata) does not cover
>* rodata and/or bss, so check each range explicitly.
> @@ -186,7 +171,7 @@ static inline const char *check_heap_object(const void 
> *ptr, unsigned long n,
>  ((unsigned long)end & (unsigned long)PAGE_MASK)))
>   return NULL;
>  
> - /* Allow if start and end are inside the same compound page. */
> + /* Allow if fully inside the same compound (__GFP_COMP) page. */
>   endpage = virt_to_head_page(end);
>   if (likely(endpage == page))
>   return NULL;
> @@ -199,20 +184,44 @@ static inline const char *check_heap_object(const void 
> *ptr, unsigned long n,
>   is_reserved = PageReserved(page);
>   is_cma = is_migrate_cma_page(page);
>   if (!is_reserved && !is_cma)
> - goto reject;
> + return "";
>  
>   for (ptr += PAGE_SIZE; ptr <= end; ptr += PAGE_SIZE) {
>   page = virt_to_head_page(ptr);
>   if (is_reserved && !PageReserved(page))
> - goto reject;
> + return "";
>   if (is_cma && !is_migrate_cma_page(page))
> - goto reject;
> + return "";
>   }
> +#endif
>  
>   return NULL;
> +}
> +
> +static inline const char *check_heap_object(const void *ptr, unsigned long n,
> + bool to_user)
> +{
> + struct page *page;
> +
> + /*
> +  * Some architectures (arm64) return true for virt_addr_valid() on
> +  * vmalloced addresses. Work around this by checking for vmalloc
> +  * first.
> +  */
> + if (is_vmalloc_addr(ptr))
> + return NULL;
> +
> + if (!virt_addr_valid(ptr))
> + return NULL;
> +
> + page = virt_to_head_page(ptr);
> +
> + /* Check slab allocator for flags and size. */
> + if (PageSlab(page))
> + return __check_heap_object(ptr, n, page);
>  
> -reject:
> - return "";
> + /* Verify objec

Re: [PATCH v2] usercopy: remove page-spanning test for now

[Sinclair Yeh]

Reviewed-by: Sinclair Yeh 

On Wed, Sep 07, 2016 at 11:08:45AM -0700, Kees Cook wrote:
> A custom allocator without __GFP_COMP that copies to userspace has been
> found in vmw_execbuf_process[1], so this disables the page-span checker
> by placing it behind a CONFIG for future work where such things can be
> tracked down later.
> 
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1373326=CwIBAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=w9Iu3o4zAy-3-s8MFvrNSQ=HmnBFNgZxprKMPy51P5NjJYN3A5FrdjyzaM817eexKU=Htqh5qkhK5mXIdzTCYiqCaZU1R98sOatRFgsoDbGOzw=
>  
> 
> Reported-by: Vinson Lee 
> Fixes: f5509cc18daa ("mm: Hardened usercopy")
> Signed-off-by: Kees Cook 
> ---
> v2:
> - split logic into separate function entirely, torvalds
> ---
>  mm/usercopy.c| 61 
> 
>  security/Kconfig | 11 ++
>  2 files changed, 46 insertions(+), 26 deletions(-)
> 
> diff --git a/mm/usercopy.c b/mm/usercopy.c
> index a3cc3052f830..089328f2b920 100644
> --- a/mm/usercopy.c
> +++ b/mm/usercopy.c
> @@ -134,31 +134,16 @@ static inline const char *check_bogus_address(const 
> void *ptr, unsigned long n)
>   return NULL;
>  }
>  
> -static inline const char *check_heap_object(const void *ptr, unsigned long n,
> - bool to_user)
> +/* Checks for allocs that are marked in some way as spanning multiple pages. 
> */
> +static inline const char *check_page_span(const void *ptr, unsigned long n,
> +   struct page *page, bool to_user)
>  {
> - struct page *page, *endpage;
> +#ifdef CONFIG_HARDENED_USERCOPY_PAGESPAN
>   const void *end = ptr + n - 1;
> + struct page *endpage;
>   bool is_reserved, is_cma;
>  
>   /*
> -  * Some architectures (arm64) return true for virt_addr_valid() on
> -  * vmalloced addresses. Work around this by checking for vmalloc
> -  * first.
> -  */
> - if (is_vmalloc_addr(ptr))
> - return NULL;
> -
> - if (!virt_addr_valid(ptr))
> - return NULL;
> -
> - page = virt_to_head_page(ptr);
> -
> - /* Check slab allocator for flags and size. */
> - if (PageSlab(page))
> - return __check_heap_object(ptr, n, page);
> -
> - /*
>* Sometimes the kernel data regions are not marked Reserved (see
>* check below). And sometimes [_sdata,_edata) does not cover
>* rodata and/or bss, so check each range explicitly.
> @@ -186,7 +171,7 @@ static inline const char *check_heap_object(const void 
> *ptr, unsigned long n,
>  ((unsigned long)end & (unsigned long)PAGE_MASK)))
>   return NULL;
>  
> - /* Allow if start and end are inside the same compound page. */
> + /* Allow if fully inside the same compound (__GFP_COMP) page. */
>   endpage = virt_to_head_page(end);
>   if (likely(endpage == page))
>   return NULL;
> @@ -199,20 +184,44 @@ static inline const char *check_heap_object(const void 
> *ptr, unsigned long n,
>   is_reserved = PageReserved(page);
>   is_cma = is_migrate_cma_page(page);
>   if (!is_reserved && !is_cma)
> - goto reject;
> + return "";
>  
>   for (ptr += PAGE_SIZE; ptr <= end; ptr += PAGE_SIZE) {
>   page = virt_to_head_page(ptr);
>   if (is_reserved && !PageReserved(page))
> - goto reject;
> + return "";
>   if (is_cma && !is_migrate_cma_page(page))
> - goto reject;
> + return "";
>   }
> +#endif
>  
>   return NULL;
> +}
> +
> +static inline const char *check_heap_object(const void *ptr, unsigned long n,
> + bool to_user)
> +{
> + struct page *page;
> +
> + /*
> +  * Some architectures (arm64) return true for virt_addr_valid() on
> +  * vmalloced addresses. Work around this by checking for vmalloc
> +  * first.
> +  */
> + if (is_vmalloc_addr(ptr))
> + return NULL;
> +
> + if (!virt_addr_valid(ptr))
> + return NULL;
> +
> + page = virt_to_head_page(ptr);
> +
> + /* Check slab allocator for flags and size. */
> + if (PageSlab(page))
> + return __check_heap_object(ptr, n, page);
>  
> -reject:
> - return "";
> + /* Verify object does not incorrectly span multiple pages. */
> + return check_page_span(ptr, n, page, to_user);

Re: [PATCH 0215/1285] Replace numeric parameter like 0444 with macro

[Sinclair Yeh]

Reviewed-by: Sinclair Yeh <s...@vmware.com>

On Tue, Aug 02, 2016 at 06:50:25PM +0800, Baole Ni wrote:
> I find that the developers often just specified the numeric value
> when calling a macro which is defined with a parameter for access permission.
> As we know, these numeric value for access permission have had the 
> corresponding macro,
> and that using macro can improve the robustness and readability of the code,
> thus, I suggest replacing the numeric parameter with the macro.
> 
> Signed-off-by: Chuansheng Liu <chuansheng@intel.com>
> Signed-off-by: Baole Ni <baolex...@intel.com>
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 9fcd820..b8e5d3d 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -240,15 +240,15 @@ static int vmwgfx_pm_notifier(struct notifier_block 
> *nb, unsigned long val,
> void *ptr);
>  
>  MODULE_PARM_DESC(enable_fbdev, "Enable vmwgfx fbdev");
> -module_param_named(enable_fbdev, enable_fbdev, int, 0600);
> +module_param_named(enable_fbdev, enable_fbdev, int, S_IRUSR | S_IWUSR);
>  MODULE_PARM_DESC(force_dma_api, "Force using the DMA API for TTM pages");
> -module_param_named(force_dma_api, vmw_force_iommu, int, 0600);
> +module_param_named(force_dma_api, vmw_force_iommu, int, S_IRUSR | S_IWUSR);
>  MODULE_PARM_DESC(restrict_iommu, "Try to limit IOMMU usage for TTM pages");
> -module_param_named(restrict_iommu, vmw_restrict_iommu, int, 0600);
> +module_param_named(restrict_iommu, vmw_restrict_iommu, int, S_IRUSR | 
> S_IWUSR);
>  MODULE_PARM_DESC(force_coherent, "Force coherent TTM pages");
> -module_param_named(force_coherent, vmw_force_coherent, int, 0600);
> +module_param_named(force_coherent, vmw_force_coherent, int, S_IRUSR | 
> S_IWUSR);
>  MODULE_PARM_DESC(restrict_dma_mask, "Restrict DMA mask to 44 bits with 
> IOMMU");
> -module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, 0600);
> +module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, S_IRUSR | 
> S_IWUSR);
>  
>  
>  static void vmw_print_capabilities(uint32_t capabilities)
> -- 
> 2.9.2
> 

Re: [PATCH 0215/1285] Replace numeric parameter like 0444 with macro

[Sinclair Yeh]

Reviewed-by: Sinclair Yeh 

On Tue, Aug 02, 2016 at 06:50:25PM +0800, Baole Ni wrote:
> I find that the developers often just specified the numeric value
> when calling a macro which is defined with a parameter for access permission.
> As we know, these numeric value for access permission have had the 
> corresponding macro,
> and that using macro can improve the robustness and readability of the code,
> thus, I suggest replacing the numeric parameter with the macro.
> 
> Signed-off-by: Chuansheng Liu 
> Signed-off-by: Baole Ni 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 9fcd820..b8e5d3d 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -240,15 +240,15 @@ static int vmwgfx_pm_notifier(struct notifier_block 
> *nb, unsigned long val,
> void *ptr);
>  
>  MODULE_PARM_DESC(enable_fbdev, "Enable vmwgfx fbdev");
> -module_param_named(enable_fbdev, enable_fbdev, int, 0600);
> +module_param_named(enable_fbdev, enable_fbdev, int, S_IRUSR | S_IWUSR);
>  MODULE_PARM_DESC(force_dma_api, "Force using the DMA API for TTM pages");
> -module_param_named(force_dma_api, vmw_force_iommu, int, 0600);
> +module_param_named(force_dma_api, vmw_force_iommu, int, S_IRUSR | S_IWUSR);
>  MODULE_PARM_DESC(restrict_iommu, "Try to limit IOMMU usage for TTM pages");
> -module_param_named(restrict_iommu, vmw_restrict_iommu, int, 0600);
> +module_param_named(restrict_iommu, vmw_restrict_iommu, int, S_IRUSR | 
> S_IWUSR);
>  MODULE_PARM_DESC(force_coherent, "Force coherent TTM pages");
> -module_param_named(force_coherent, vmw_force_coherent, int, 0600);
> +module_param_named(force_coherent, vmw_force_coherent, int, S_IRUSR | 
> S_IWUSR);
>  MODULE_PARM_DESC(restrict_dma_mask, "Restrict DMA mask to 44 bits with 
> IOMMU");
> -module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, 0600);
> +module_param_named(restrict_dma_mask, vmw_restrict_dma_mask, int, S_IRUSR | 
> S_IWUSR);
>  
>  
>  static void vmw_print_capabilities(uint32_t capabilities)
> -- 
> 2.9.2
> 

Re: [PATCH] drm/vmwgfx: Delete an unnecessary check before the function call "vfree"

[Sinclair Yeh]

Looks good.  Thanks!

Reviewed-by: Sinclair Yeh <s...@vmware.com>

On Fri, Jul 22, 2016 at 01:45:40PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Fri, 22 Jul 2016 13:31:00 +0200
> 
> The vfree() function performs also input parameter validation.
> Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index 1a1a87c..dc5beff 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -3625,9 +3625,7 @@ static int vmw_resize_cmd_bounce(struct vmw_sw_context 
> *sw_context,
>  (sw_context->cmd_bounce_size >> 1));
>   }
>  
> - if (sw_context->cmd_bounce != NULL)
> - vfree(sw_context->cmd_bounce);
> -
> + vfree(sw_context->cmd_bounce);
>   sw_context->cmd_bounce = vmalloc(sw_context->cmd_bounce_size);
>  
>   if (sw_context->cmd_bounce == NULL) {
> -- 
> 2.9.2
> 

Re: [PATCH] drm/vmwgfx: Delete an unnecessary check before the function call "vfree"

[Sinclair Yeh]

Looks good.  Thanks!

Reviewed-by: Sinclair Yeh 

On Fri, Jul 22, 2016 at 01:45:40PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Fri, 22 Jul 2016 13:31:00 +0200
> 
> The vfree() function performs also input parameter validation.
> Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index 1a1a87c..dc5beff 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -3625,9 +3625,7 @@ static int vmw_resize_cmd_bounce(struct vmw_sw_context 
> *sw_context,
>  (sw_context->cmd_bounce_size >> 1));
>   }
>  
> - if (sw_context->cmd_bounce != NULL)
> - vfree(sw_context->cmd_bounce);
> -
> + vfree(sw_context->cmd_bounce);
>   sw_context->cmd_bounce = vmalloc(sw_context->cmd_bounce_size);
>  
>   if (sw_context->cmd_bounce == NULL) {
> -- 
> 2.9.2
> 

Re: [PATCH 6/6] VMware balloon: Update vmw_balloon.c to use the VMW_PORT macro

[Sinclair Yeh]

On Thu, Mar 31, 2016 at 09:30:37AM -0700, Greg KH wrote:
> On Thu, Mar 31, 2016 at 07:39:53AM -0700, Sinclair Yeh wrote:
> > Hi,
> > 
> > Does any one know when this series will be applied?
> 
> No idea, it's not going through my tree, as I don't have these in my
> queue anymore...

Ok, I'm not sure what else to do.  I've already updated the series once
because it didn't get picked up last December.  Can anyone on the x86 list
pick this up?

Sinclair

Re: [PATCH 6/6] VMware balloon: Update vmw_balloon.c to use the VMW_PORT macro

[Sinclair Yeh]

On Thu, Mar 31, 2016 at 09:30:37AM -0700, Greg KH wrote:
> On Thu, Mar 31, 2016 at 07:39:53AM -0700, Sinclair Yeh wrote:
> > Hi,
> > 
> > Does any one know when this series will be applied?
> 
> No idea, it's not going through my tree, as I don't have these in my
> queue anymore...

Ok, I'm not sure what else to do.  I've already updated the series once
because it didn't get picked up last December.  Can anyone on the x86 list
pick this up?

Sinclair

Re: [PATCH 6/6] VMware balloon: Update vmw_balloon.c to use the VMW_PORT macro

[Sinclair Yeh]

Hi,

Does any one know when this series will be applied?

Sinclair

On Mon, Feb 08, 2016 at 11:41:57AM -0800, Greg KH wrote:
> On Tue, Jan 19, 2016 at 01:46:05PM -0800, Sinclair Yeh wrote:
> > Updated VMWARE_BALLOON_CMD to use the common VMW_PORT macro.
> > Doing this rather than replacing all instances of VMWARE_BALLOON_CMD
> > to minimize code change.
> > 
> > Signed-off-by: Sinclair Yeh <s...@vmware.com>
> > Reviewed-by: Thomas Hellstrom <thellst...@vmware.com>
> > Reviewed-by: Alok N Kataria <akata...@vmware.com>
> > Acked-by: Xavier Deguillard <xdeguill...@vmware.com>
> > Cc: pv-driv...@vmware.com
> > Cc: Xavier Deguillard <xdeguill...@vmware.com>
> > Cc: linux-kernel@vger.kernel.org
> > Cc: virtualizat...@lists.linux-foundation.org
> > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> 
> 
> Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> 
> > -#define VMWARE_BALLOON_CMD(cmd, arg1, arg2, result)\
> > -({ \
> > -   unsigned long __status, __dummy1, __dummy2, __dummy3;   \
> > -   __asm__ __volatile__ ("inl %%dx" :  \
> > -   "=a"(__status), \
> > -   "=c"(__dummy1), \
> > -   "=d"(__dummy2), \
> > -   "=b"(result),   \
> > -   "=S" (__dummy3) :   \
> > -   "0"(VMW_BALLOON_HV_MAGIC),  \
> > -   "1"(VMW_BALLOON_CMD_##cmd), \
> > -   "2"(VMW_BALLOON_HV_PORT),   \
> > -   "3"(arg1),  \
> > -   "4" (arg2) :\
> > -   "memory");  \
> > -   if (VMW_BALLOON_CMD_##cmd == VMW_BALLOON_CMD_START) \
> > -   result = __dummy1;  \
> > -   result &= -1UL; \
> > -   __status & -1UL;\
> > +#define VMWARE_BALLOON_CMD(cmd, arg1, arg2, result)
> > \
> > +({ \
> > +   unsigned long __status, __dummy1, __dummy2; \
> > +   unsigned long __si, __di;   \
> > +   VMW_PORT(VMW_BALLOON_CMD_##cmd, arg1, arg2, 0,  \
> > +VMW_BALLOON_HV_PORT, VMW_BALLOON_HV_MAGIC, \
> > +__status, result, __dummy1, __dummy2, __si, __di); \
> > +   if (VMW_BALLOON_CMD_##cmd == VMW_BALLOON_CMD_START) \
> > +   result = __dummy1;  \
> > +   result &= -1UL; \
> > +   __status & -1UL;\
> >  })
> 
> Honestly, it doesn't look anymore "readable" to me, but it's your code
> to maintain, not mine... :)
> 

Re: [PATCH 6/6] VMware balloon: Update vmw_balloon.c to use the VMW_PORT macro

[Sinclair Yeh]

Hi,

Does any one know when this series will be applied?

Sinclair

On Mon, Feb 08, 2016 at 11:41:57AM -0800, Greg KH wrote:
> On Tue, Jan 19, 2016 at 01:46:05PM -0800, Sinclair Yeh wrote:
> > Updated VMWARE_BALLOON_CMD to use the common VMW_PORT macro.
> > Doing this rather than replacing all instances of VMWARE_BALLOON_CMD
> > to minimize code change.
> > 
> > Signed-off-by: Sinclair Yeh 
> > Reviewed-by: Thomas Hellstrom 
> > Reviewed-by: Alok N Kataria 
> > Acked-by: Xavier Deguillard 
> > Cc: pv-driv...@vmware.com
> > Cc: Xavier Deguillard 
> > Cc: linux-kernel@vger.kernel.org
> > Cc: virtualizat...@lists.linux-foundation.org
> > Cc: Greg Kroah-Hartman 
> 
> 
> Acked-by: Greg Kroah-Hartman 
> 
> > -#define VMWARE_BALLOON_CMD(cmd, arg1, arg2, result)\
> > -({ \
> > -   unsigned long __status, __dummy1, __dummy2, __dummy3;   \
> > -   __asm__ __volatile__ ("inl %%dx" :  \
> > -   "=a"(__status), \
> > -   "=c"(__dummy1), \
> > -   "=d"(__dummy2), \
> > -   "=b"(result),   \
> > -   "=S" (__dummy3) :   \
> > -   "0"(VMW_BALLOON_HV_MAGIC),  \
> > -   "1"(VMW_BALLOON_CMD_##cmd), \
> > -   "2"(VMW_BALLOON_HV_PORT),   \
> > -   "3"(arg1),  \
> > -   "4" (arg2) :\
> > -   "memory");  \
> > -   if (VMW_BALLOON_CMD_##cmd == VMW_BALLOON_CMD_START) \
> > -   result = __dummy1;  \
> > -   result &= -1UL; \
> > -   __status & -1UL;\
> > +#define VMWARE_BALLOON_CMD(cmd, arg1, arg2, result)
> > \
> > +({ \
> > +   unsigned long __status, __dummy1, __dummy2; \
> > +   unsigned long __si, __di;   \
> > +   VMW_PORT(VMW_BALLOON_CMD_##cmd, arg1, arg2, 0,  \
> > +VMW_BALLOON_HV_PORT, VMW_BALLOON_HV_MAGIC, \
> > +__status, result, __dummy1, __dummy2, __si, __di); \
> > +   if (VMW_BALLOON_CMD_##cmd == VMW_BALLOON_CMD_START) \
> > +   result = __dummy1;  \
> > +   result &= -1UL; \
> > +   __status & -1UL;\
> >  })
> 
> Honestly, it doesn't look anymore "readable" to me, but it's your code
> to maintain, not mine... :)
> 

[PATCH 2/6] x86: Update vmware.c to use the common VMW_PORT macros

[Sinclair Yeh]

Updated the VMWARE_PORT macro to use the new VMW_PORT
macro.  Doing this instead of replacing all existing
instances of VMWARE_PORT to minimize code change.

Signed-off-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
Reviewed-by: Alok N Kataria 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: pv-driv...@vmware.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman 

---

v2:
Instead of replacing all existing instances of VMWARE_PORT
with VMW_PORT, update VMWARE_PORT to use the new VMW_PORT.

v3:
Using updated VMWARE_PORT() macro, which needs hypervisor magic in the
parameter

v4:
Swapped the first and second parameters because VMW_PORT has
changed.
---
 arch/x86/kernel/cpu/vmware.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 628a059..67c429d 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define CPUID_VMWARE_INFO_LEAF 0x4000
 #define VMWARE_HYPERVISOR_MAGIC0x564D5868
@@ -37,13 +38,14 @@
 #define VMWARE_PORT_CMD_LEGACY_X2APIC  3
 #define VMWARE_PORT_CMD_VCPU_RESERVED  31
 
-#define VMWARE_PORT(cmd, eax, ebx, ecx, edx)   \
-   __asm__("inl (%%dx)" :  \
-   "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) :\
-   "0"(VMWARE_HYPERVISOR_MAGIC),   \
-   "1"(VMWARE_PORT_CMD_##cmd), \
-   "2"(VMWARE_HYPERVISOR_PORT), "3"(UINT_MAX) :\
-   "memory");
+#define VMWARE_PORT(cmd, eax, ebx, ecx, edx) \
+({   \
+   unsigned long __si = 0, __di = 0; \
+   VMW_PORT(VMWARE_PORT_CMD_##cmd, UINT_MAX, VMWARE_HYPERVISOR_PORT, \
+VMWARE_HYPERVISOR_MAGIC, \
+eax, ebx, ecx, edx, __si, __di); \
+})
+
 
 static inline int __vmware_platform(void)
 {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/6] Input: Remove vmmouse port reservation

[Sinclair Yeh]

This port is used by quite a few guest-to-host communication
capabilities, e.g. getting configuration, logging, etc.  Currently
multiple kernel modules, and one or more priviledged guest user
mode app, e.g. open-vm-tools, use this port without reservation.

It was determined that no reservation is required when accessing
the port in this manner.

Signed-off-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
Cc: pv-driv...@vmware.com
Cc: linux-graphics-maintai...@vmware.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman 
---
 drivers/input/mouse/vmmouse.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
index ddb152c..e881c87 100644
--- a/drivers/input/mouse/vmmouse.c
+++ b/drivers/input/mouse/vmmouse.c
@@ -347,16 +347,10 @@ int vmmouse_detect(struct psmouse *psmouse, bool 
set_properties)
return -ENXIO;
}
 
-   if (!request_region(VMMOUSE_PROTO_PORT, 4, "vmmouse")) {
-   psmouse_dbg(psmouse, "VMMouse port in use.\n");
-   return -EBUSY;
-   }
-
/* Check if the device is present */
response = ~VMMOUSE_PROTO_MAGIC;
VMMOUSE_CMD(GETVERSION, 0, version, response, dummy1, dummy2);
if (response != VMMOUSE_PROTO_MAGIC || version == 0xU) {
-   release_region(VMMOUSE_PROTO_PORT, 4);
return -ENXIO;
}
 
@@ -366,8 +360,6 @@ int vmmouse_detect(struct psmouse *psmouse, bool 
set_properties)
psmouse->model = version;
}
 
-   release_region(VMMOUSE_PROTO_PORT, 4);
-
return 0;
 }
 
@@ -386,7 +378,6 @@ static void vmmouse_disconnect(struct psmouse *psmouse)
psmouse_reset(psmouse);
input_unregister_device(priv->abs_dev);
kfree(priv);
-   release_region(VMMOUSE_PROTO_PORT, 4);
 }
 
 /**
@@ -430,15 +421,10 @@ int vmmouse_init(struct psmouse *psmouse)
struct input_dev *rel_dev = psmouse->dev, *abs_dev;
int error;
 
-   if (!request_region(VMMOUSE_PROTO_PORT, 4, "vmmouse")) {
-   psmouse_dbg(psmouse, "VMMouse port in use.\n");
-   return -EBUSY;
-   }
-
psmouse_reset(psmouse);
error = vmmouse_enable(psmouse);
if (error)
-   goto release_region;
+   return error;
 
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
abs_dev = input_allocate_device();
@@ -493,8 +479,5 @@ init_fail:
kfree(priv);
psmouse->private = NULL;
 
-release_region:
-   release_region(VMMOUSE_PROTO_PORT, 4);
-
return error;
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/6] VMware balloon: Update vmw_balloon.c to use the VMW_PORT macro

[Sinclair Yeh]

Updated VMWARE_BALLOON_CMD to use the common VMW_PORT macro.
Doing this rather than replacing all instances of VMWARE_BALLOON_CMD
to minimize code change.

Signed-off-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
Reviewed-by: Alok N Kataria 
Cc: pv-driv...@vmware.com
Cc: Xavier Deguillard 
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: Greg Kroah-Hartman 

---
v1
Swapped parameters 1 and 2 to VMW_PORT because the macro has been
updated
---
 drivers/misc/vmw_balloon.c | 29 -
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
index ffb5634..f8f60ca 100644
--- a/drivers/misc/vmw_balloon.c
+++ b/drivers/misc/vmw_balloon.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_AUTHOR("VMware, Inc.");
 MODULE_DESCRIPTION("VMware Memory Control (Balloon) Driver");
@@ -142,23 +143,17 @@ enum vmwballoon_capabilities {
 
 #define VMW_BALLOON_SUCCESS_WITH_CAPABILITIES  (0x0300)
 
-#define VMWARE_BALLOON_CMD(cmd, data, result)  \
-({ \
-   unsigned long __status, __dummy1, __dummy2; \
-   __asm__ __volatile__ ("inl %%dx" :  \
-   "=a"(__status), \
-   "=c"(__dummy1), \
-   "=d"(__dummy2), \
-   "=b"(result) :  \
-   "0"(VMW_BALLOON_HV_MAGIC),  \
-   "1"(VMW_BALLOON_CMD_##cmd), \
-   "2"(VMW_BALLOON_HV_PORT),   \
-   "3"(data) : \
-   "memory");  \
-   if (VMW_BALLOON_CMD_##cmd == VMW_BALLOON_CMD_START) \
-   result = __dummy1;  \
-   result &= -1UL; \
-   __status & -1UL;\
+#define VMWARE_BALLOON_CMD(cmd, data, result) \
+({\
+   unsigned long __status, __dummy1, __dummy2;\
+   unsigned long __si = 0, __di = 0;  \
+   VMW_PORT(VMW_BALLOON_CMD_##cmd, data, VMW_BALLOON_HV_PORT, \
+VMW_BALLOON_HV_MAGIC, \
+__status, result, __dummy1, __dummy2, __si, __di);\
+   if (VMW_BALLOON_CMD_##cmd == VMW_BALLOON_CMD_START)\
+   result = __dummy1; \
+   result &= -1UL;\
+   __status & -1UL;   \
 })
 
 #ifdef CONFIG_DEBUG_FS
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Sinclair Yeh]

Updated the VMMOUSE macro to use the new VMW_PORT macro. Doing
this instead of replacing all existing instances of VMWMOUSE
to minimize code change.

Signed-off-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
Reviewed-by: Alok N Kataria 
Cc: pv-driv...@vmware.com
Cc: linux-graphics-maintai...@vmware.com
Cc: Dmitry Torokhov 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-in...@vger.kernel.org

---

v2:
Instead of replacing existing VMMOUSE defines, only modify enough
to use the new VMW_PORT define.

v3:
Use updated VMWARE_PORT() which requires hypervisor magic as an added
parameter

v4:
Swapped parameters 1 and 2 when calling VMW_PORT because the macro
has been updated
---
 drivers/input/mouse/vmmouse.c | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
index e272f06..ddb152c 100644
--- a/drivers/input/mouse/vmmouse.c
+++ b/drivers/input/mouse/vmmouse.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "psmouse.h"
 #include "vmmouse.h"
@@ -84,21 +85,12 @@ struct vmmouse_data {
  * implementing the vmmouse protocol. Should never execute on
  * bare metal hardware.
  */
-#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
-({ \
-   unsigned long __dummy1, __dummy2;   \
-   __asm__ __volatile__ ("inl %%dx" :  \
-   "=a"(out1), \
-   "=b"(out2), \
-   "=c"(out3), \
-   "=d"(out4), \
-   "=S"(__dummy1), \
-   "=D"(__dummy2) :\
-   "a"(VMMOUSE_PROTO_MAGIC),   \
-   "b"(in1),   \
-   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
-   "d"(VMMOUSE_PROTO_PORT) :   \
-   "memory");  \
+#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4) \
+({\
+   unsigned long __dummy1 = 0, __dummy2 = 0;  \
+   VMW_PORT(VMMOUSE_PROTO_CMD_##cmd, in1, VMMOUSE_PROTO_PORT, \
+VMMOUSE_PROTO_MAGIC,  \
+out1, out2, out3, out4, __dummy1, __dummy2);  \
 })
 
 /**
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/6] x86: Remove address from the vmware.c header

[Sinclair Yeh]

We should no longer have mailing address of Free Software
Foundation in the copyright header.  Since this patch series
touches this file, taking this opportunity to fix the header.

Signed-off-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
Reviewed-by: Alok N Kataria 
Cc: pv-driv...@vmware.com
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman 
---
 arch/x86/kernel/cpu/vmware.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 67c429d..c157c4b 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -15,10 +15,6 @@
  * NON INFRINGEMENT.  See the GNU General Public License for more
  * details.
  *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
- *
  */
 
 #include 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/6] x86: Add VMWare Host Communication Macros

[Sinclair Yeh]

These macros will be used by multiple VMWare modules for handling
host communication.

Signed-off-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
Reviewed-by: Alok N Kataria 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Alok Kataria 
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: Xavier Deguillard 
Cc: Greg Kroah-Hartman 

---

v2:
* Keeping only the minimal common platform defines
* added vmware_platform() check function

v3:
* Added new field to handle different hypervisor magic values

v4:
* Make it so that "cmd" is always the first parameter for both
  High-Bandwidh and non-High-Bandwidth version of the macro
* Addressed comments from H. Peter Anvin on the assembly code
---
 arch/x86/include/asm/vmware.h | 126 ++
 1 file changed, 126 insertions(+)
 create mode 100644 arch/x86/include/asm/vmware.h

diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
new file mode 100644
index 000..ad359e0
--- /dev/null
+++ b/arch/x86/include/asm/vmware.h
@@ -0,0 +1,126 @@
+/*
+ * Copyright (C) 2015, VMware, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT.  See the GNU General Public License for more
+ * details.
+ *
+ * Based on code from vmware.c and vmmouse.c.
+ * Author:
+ *   Sinclair Yeh 
+ */
+#ifndef _ASM_X86_VMWARE_H
+#define _ASM_X86_VMWARE_H
+
+
+/**
+ * Hypervisor-specific bi-directional communication channel.  Should never
+ * execute on bare metal hardware.  The caller must make sure to check for
+ * supported hypervisor before using these macros.
+ *
+ * The last two parameters are both input and output and must be initialized.
+ *
+ * @cmd: [IN] Message Cmd
+ * @in1: [IN] Message Len
+ * @port_num: [IN] port number + [channel id]
+ * @magic: [IN] hypervisor magic value
+ * @eax: [OUT] value of EAX register
+ * @ebx: [OUT] e.g. status from an HB message status command
+ * @ecx: [OUT] e.g. status from a non-HB message status command
+ * @edx: [OUT] e.g. channel id
+ * @si: [INOUT] set to 0 if not used
+ * @di: [INOUT] set to 0 if not used
+ */
+#define VMW_PORT(cmd, in1, port_num, magic, eax, ebx, ecx, edx, si, di)
\
+({ \
+   asm volatile ("inl %%dx, %%eax;" :  \
+   "=a"(eax),  \
+   "=b"(ebx),  \
+   "=c"(ecx),  \
+   "=d"(edx),  \
+   "=S"(si),   \
+   "=D"(di) :  \
+   "a"(magic), \
+   "b"(in1),   \
+   "c"(cmd),   \
+   "d"(port_num),  \
+   "S"(si),\
+   "D"(di) :   \
+   "memory");  \
+})
+
+
+/**
+ * Hypervisor-specific bi-directional communication channel.  Should never
+ * execute on bare metal hardware.  The caller must make sure to check for
+ * supported hypervisor before using these macros.
+ *
+ * The last 3 parameters are both input and output and must be initialized.
+ *
+ * @cmd: [IN] Message Cmd
+ * @in1: [IN] Message Len
+ * @port_num: [IN] port number + [channel id]
+ * @magic: [IN] hypervisor magic value
+ * @eax: [OUT] value of EAX register
+ * @ebx: [OUT] e.g. status from an HB message status command
+ * @ecx: [OUT] e.g. status from a non-HB message status command
+ * @edx: [OUT] e.g. channel id
+ * @si: [INOUT] set to 0 if not used
+ * @di: [INOUT] set to 0 if not used
+ * @bp: [INOUT] set to 0 if not used
+ */
+#define VMW_PORT_HB_OUT(cmd, in1, port_num, magic, \
+   eax, ebx, ecx, edx, si, di, bp) \
+({ \
+   asm volatile ("push %%rbp;" \
+   "xchgq %6, %%rbp;"  \
+   &q

Re: [PATCH 1/6] x86: Add VMWare Host Communication Macros

[Sinclair Yeh]

Thanks Peter.


On Tue, Dec 01, 2015 at 02:49:11PM -0800, H. Peter Anvin wrote:
> On 12/01/15 14:18, Sinclair Yeh wrote:
> > These macros will be used by multiple VMWare modules for handling
> > host communication.
> 
> > +   __asm__ __volatile__ ("inl %%dx" :  \
> 
> This is odd at best; the standard assembly form of this instruction is:
> 
>   inl (%dx),%eax

Ok, I'm not sure why this worked and compiled before.  Fixed.

> 
> Also, we don't need the underscored forms of asm and volatile for kernel
> code.
> 
> > +   __asm__ __volatile__ ("movq %13, %%rbp;"\
> > +   "cld; rep outsb; "  \
> > +   "movq %%rbp, %6" :  \
> 
> cld shouldn't be necessary here, DF=0 is part of the normal ABI environment.
> 
> You also don't save/restore %rbp here, but you do below?  Seems very odd.

Good catch.  Fixed.

> 
> It might be better do so something like:
> 
> +#define VMW_PORT_HB_OUT(in1, in2, port_num, magic, \
> + eax, ebx, ecx, edx, si, di, bp) \
> +({ \
> + __asm__ __volatile__ ("xchgq %6, %%rbp;"\
> + "cld; rep outsb; "  \
> + "xchgq %%rbp, %6" : \
> + "=a"(eax),  \
> + "=b"(ebx),  \
> + "=c"(ecx),  \
> + "=d"(edx),  \
> + "+S"(si),   \
> + "+D"(di),   \
> + "+r"(bp) :  \
> + "a"(magic), \
> + "b"(in1),   \
> + "c"(in2),   \
> + "d"(port_num) : \
> + "memory", "cc");\
> +})

This is great.  Changed.

Updated patch set incoming.

Sinclair

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/6] VMware balloon: Update vmw_balloon.c to use the VMW_PORT macro

[Sinclair Yeh]

Updated VMWARE_BALLOON_CMD to use the common VMW_PORT macro.
Doing this rather than replacing all instances of VMWARE_BALLOON_CMD
to minimize code change.

Signed-off-by: Sinclair Yeh <s...@vmware.com>
Reviewed-by: Thomas Hellstrom <thellst...@vmware.com>
Reviewed-by: Alok N Kataria <akata...@vmware.com>
Cc: pv-driv...@vmware.com
Cc: Xavier Deguillard <xdeguill...@vmware.com>
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
v1
Swapped parameters 1 and 2 to VMW_PORT because the macro has been
updated
---
 drivers/misc/vmw_balloon.c | 29 -
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
index ffb5634..f8f60ca 100644
--- a/drivers/misc/vmw_balloon.c
+++ b/drivers/misc/vmw_balloon.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_AUTHOR("VMware, Inc.");
 MODULE_DESCRIPTION("VMware Memory Control (Balloon) Driver");
@@ -142,23 +143,17 @@ enum vmwballoon_capabilities {
 
 #define VMW_BALLOON_SUCCESS_WITH_CAPABILITIES  (0x0300)
 
-#define VMWARE_BALLOON_CMD(cmd, data, result)  \
-({ \
-   unsigned long __status, __dummy1, __dummy2; \
-   __asm__ __volatile__ ("inl %%dx" :  \
-   "=a"(__status), \
-   "=c"(__dummy1), \
-   "=d"(__dummy2), \
-   "=b"(result) :  \
-   "0"(VMW_BALLOON_HV_MAGIC),  \
-   "1"(VMW_BALLOON_CMD_##cmd), \
-   "2"(VMW_BALLOON_HV_PORT),   \
-   "3"(data) : \
-   "memory");  \
-   if (VMW_BALLOON_CMD_##cmd == VMW_BALLOON_CMD_START) \
-   result = __dummy1;  \
-   result &= -1UL; \
-   __status & -1UL;\
+#define VMWARE_BALLOON_CMD(cmd, data, result) \
+({\
+   unsigned long __status, __dummy1, __dummy2;\
+   unsigned long __si = 0, __di = 0;  \
+   VMW_PORT(VMW_BALLOON_CMD_##cmd, data, VMW_BALLOON_HV_PORT, \
+VMW_BALLOON_HV_MAGIC, \
+__status, result, __dummy1, __dummy2, __si, __di);\
+   if (VMW_BALLOON_CMD_##cmd == VMW_BALLOON_CMD_START)\
+   result = __dummy1; \
+   result &= -1UL;\
+   __status & -1UL;   \
 })
 
 #ifdef CONFIG_DEBUG_FS
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Sinclair Yeh]

Updated the VMMOUSE macro to use the new VMW_PORT macro. Doing
this instead of replacing all existing instances of VMWMOUSE
to minimize code change.

Signed-off-by: Sinclair Yeh <s...@vmware.com>
Reviewed-by: Thomas Hellstrom <thellst...@vmware.com>
Reviewed-by: Alok N Kataria <akata...@vmware.com>
Cc: pv-driv...@vmware.com
Cc: linux-graphics-maintai...@vmware.com
Cc: Dmitry Torokhov <dmitry.torok...@gmail.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-in...@vger.kernel.org

---

v2:
Instead of replacing existing VMMOUSE defines, only modify enough
to use the new VMW_PORT define.

v3:
Use updated VMWARE_PORT() which requires hypervisor magic as an added
parameter

v4:
Swapped parameters 1 and 2 when calling VMW_PORT because the macro
has been updated
---
 drivers/input/mouse/vmmouse.c | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
index e272f06..ddb152c 100644
--- a/drivers/input/mouse/vmmouse.c
+++ b/drivers/input/mouse/vmmouse.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "psmouse.h"
 #include "vmmouse.h"
@@ -84,21 +85,12 @@ struct vmmouse_data {
  * implementing the vmmouse protocol. Should never execute on
  * bare metal hardware.
  */
-#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
-({ \
-   unsigned long __dummy1, __dummy2;   \
-   __asm__ __volatile__ ("inl %%dx" :  \
-   "=a"(out1), \
-   "=b"(out2), \
-   "=c"(out3), \
-   "=d"(out4), \
-   "=S"(__dummy1), \
-   "=D"(__dummy2) :\
-   "a"(VMMOUSE_PROTO_MAGIC),   \
-   "b"(in1),   \
-   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
-   "d"(VMMOUSE_PROTO_PORT) :   \
-   "memory");  \
+#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4) \
+({\
+   unsigned long __dummy1 = 0, __dummy2 = 0;  \
+   VMW_PORT(VMMOUSE_PROTO_CMD_##cmd, in1, VMMOUSE_PROTO_PORT, \
+VMMOUSE_PROTO_MAGIC,  \
+out1, out2, out3, out4, __dummy1, __dummy2);  \
 })
 
 /**
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/6] x86: Remove address from the vmware.c header

[Sinclair Yeh]

We should no longer have mailing address of Free Software
Foundation in the copyright header.  Since this patch series
touches this file, taking this opportunity to fix the header.

Signed-off-by: Sinclair Yeh <s...@vmware.com>
Reviewed-by: Thomas Hellstrom <thellst...@vmware.com>
Reviewed-by: Alok N Kataria <akata...@vmware.com>
Cc: pv-driv...@vmware.com
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 arch/x86/kernel/cpu/vmware.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 67c429d..c157c4b 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -15,10 +15,6 @@
  * NON INFRINGEMENT.  See the GNU General Public License for more
  * details.
  *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
- *
  */
 
 #include 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/6] x86: Add VMWare Host Communication Macros

[Sinclair Yeh]

These macros will be used by multiple VMWare modules for handling
host communication.

Signed-off-by: Sinclair Yeh <s...@vmware.com>
Reviewed-by: Thomas Hellstrom <thellst...@vmware.com>
Reviewed-by: Alok N Kataria <akata...@vmware.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: Alok Kataria <akata...@vmware.com>
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: Xavier Deguillard <xdeguill...@vmware.com>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---

v2:
* Keeping only the minimal common platform defines
* added vmware_platform() check function

v3:
* Added new field to handle different hypervisor magic values

v4:
* Make it so that "cmd" is always the first parameter for both
  High-Bandwidh and non-High-Bandwidth version of the macro
* Addressed comments from H. Peter Anvin on the assembly code
---
 arch/x86/include/asm/vmware.h | 126 ++
 1 file changed, 126 insertions(+)
 create mode 100644 arch/x86/include/asm/vmware.h

diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
new file mode 100644
index 000..ad359e0
--- /dev/null
+++ b/arch/x86/include/asm/vmware.h
@@ -0,0 +1,126 @@
+/*
+ * Copyright (C) 2015, VMware, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT.  See the GNU General Public License for more
+ * details.
+ *
+ * Based on code from vmware.c and vmmouse.c.
+ * Author:
+ *   Sinclair Yeh <s...@vmware.com>
+ */
+#ifndef _ASM_X86_VMWARE_H
+#define _ASM_X86_VMWARE_H
+
+
+/**
+ * Hypervisor-specific bi-directional communication channel.  Should never
+ * execute on bare metal hardware.  The caller must make sure to check for
+ * supported hypervisor before using these macros.
+ *
+ * The last two parameters are both input and output and must be initialized.
+ *
+ * @cmd: [IN] Message Cmd
+ * @in1: [IN] Message Len
+ * @port_num: [IN] port number + [channel id]
+ * @magic: [IN] hypervisor magic value
+ * @eax: [OUT] value of EAX register
+ * @ebx: [OUT] e.g. status from an HB message status command
+ * @ecx: [OUT] e.g. status from a non-HB message status command
+ * @edx: [OUT] e.g. channel id
+ * @si: [INOUT] set to 0 if not used
+ * @di: [INOUT] set to 0 if not used
+ */
+#define VMW_PORT(cmd, in1, port_num, magic, eax, ebx, ecx, edx, si, di)
\
+({ \
+   asm volatile ("inl %%dx, %%eax;" :  \
+   "=a"(eax),  \
+   "=b"(ebx),  \
+   "=c"(ecx),  \
+   "=d"(edx),  \
+   "=S"(si),   \
+   "=D"(di) :  \
+   "a"(magic), \
+   "b"(in1),   \
+   "c"(cmd),   \
+   "d"(port_num),  \
+   "S"(si),\
+   "D"(di) :   \
+   "memory");  \
+})
+
+
+/**
+ * Hypervisor-specific bi-directional communication channel.  Should never
+ * execute on bare metal hardware.  The caller must make sure to check for
+ * supported hypervisor before using these macros.
+ *
+ * The last 3 parameters are both input and output and must be initialized.
+ *
+ * @cmd: [IN] Message Cmd
+ * @in1: [IN] Message Len
+ * @port_num: [IN] port number + [channel id]
+ * @magic: [IN] hypervisor magic value
+ * @eax: [OUT] value of EAX register
+ * @ebx: [OUT] e.g. status from an HB message status command
+ * @ecx: [OUT] e.g. status from a non-HB message status command
+ * @edx: [OUT] e.g. channel id
+ * @si: [INOUT] set to 0 if not used
+ * @di: [INOUT] set to 0 if not used
+ * @bp: [INOUT] set to 0 if not used
+ */
+#define VMW_PORT_HB_OUT(cmd, in1, port_num,

[PATCH 4/6] Input: Remove vmmouse port reservation

[Sinclair Yeh]

This port is used by quite a few guest-to-host communication
capabilities, e.g. getting configuration, logging, etc.  Currently
multiple kernel modules, and one or more priviledged guest user
mode app, e.g. open-vm-tools, use this port without reservation.

It was determined that no reservation is required when accessing
the port in this manner.

Signed-off-by: Sinclair Yeh <s...@vmware.com>
Reviewed-by: Thomas Hellstrom <thellst...@vmware.com>
Cc: pv-driv...@vmware.com
Cc: linux-graphics-maintai...@vmware.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/input/mouse/vmmouse.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
index ddb152c..e881c87 100644
--- a/drivers/input/mouse/vmmouse.c
+++ b/drivers/input/mouse/vmmouse.c
@@ -347,16 +347,10 @@ int vmmouse_detect(struct psmouse *psmouse, bool 
set_properties)
return -ENXIO;
}
 
-   if (!request_region(VMMOUSE_PROTO_PORT, 4, "vmmouse")) {
-   psmouse_dbg(psmouse, "VMMouse port in use.\n");
-   return -EBUSY;
-   }
-
/* Check if the device is present */
response = ~VMMOUSE_PROTO_MAGIC;
VMMOUSE_CMD(GETVERSION, 0, version, response, dummy1, dummy2);
if (response != VMMOUSE_PROTO_MAGIC || version == 0xU) {
-   release_region(VMMOUSE_PROTO_PORT, 4);
return -ENXIO;
}
 
@@ -366,8 +360,6 @@ int vmmouse_detect(struct psmouse *psmouse, bool 
set_properties)
psmouse->model = version;
}
 
-   release_region(VMMOUSE_PROTO_PORT, 4);
-
return 0;
 }
 
@@ -386,7 +378,6 @@ static void vmmouse_disconnect(struct psmouse *psmouse)
psmouse_reset(psmouse);
input_unregister_device(priv->abs_dev);
kfree(priv);
-   release_region(VMMOUSE_PROTO_PORT, 4);
 }
 
 /**
@@ -430,15 +421,10 @@ int vmmouse_init(struct psmouse *psmouse)
struct input_dev *rel_dev = psmouse->dev, *abs_dev;
int error;
 
-   if (!request_region(VMMOUSE_PROTO_PORT, 4, "vmmouse")) {
-   psmouse_dbg(psmouse, "VMMouse port in use.\n");
-   return -EBUSY;
-   }
-
psmouse_reset(psmouse);
error = vmmouse_enable(psmouse);
if (error)
-   goto release_region;
+   return error;
 
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
abs_dev = input_allocate_device();
@@ -493,8 +479,5 @@ init_fail:
kfree(priv);
psmouse->private = NULL;
 
-release_region:
-   release_region(VMMOUSE_PROTO_PORT, 4);
-
return error;
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/6] x86: Update vmware.c to use the common VMW_PORT macros

[Sinclair Yeh]

Updated the VMWARE_PORT macro to use the new VMW_PORT
macro.  Doing this instead of replacing all existing
instances of VMWARE_PORT to minimize code change.

Signed-off-by: Sinclair Yeh <s...@vmware.com>
Reviewed-by: Thomas Hellstrom <thellst...@vmware.com>
Reviewed-by: Alok N Kataria <akata...@vmware.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: pv-driv...@vmware.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---

v2:
Instead of replacing all existing instances of VMWARE_PORT
with VMW_PORT, update VMWARE_PORT to use the new VMW_PORT.

v3:
Using updated VMWARE_PORT() macro, which needs hypervisor magic in the
parameter

v4:
Swapped the first and second parameters because VMW_PORT has
changed.
---
 arch/x86/kernel/cpu/vmware.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 628a059..67c429d 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define CPUID_VMWARE_INFO_LEAF 0x4000
 #define VMWARE_HYPERVISOR_MAGIC0x564D5868
@@ -37,13 +38,14 @@
 #define VMWARE_PORT_CMD_LEGACY_X2APIC  3
 #define VMWARE_PORT_CMD_VCPU_RESERVED  31
 
-#define VMWARE_PORT(cmd, eax, ebx, ecx, edx)   \
-   __asm__("inl (%%dx)" :  \
-   "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) :\
-   "0"(VMWARE_HYPERVISOR_MAGIC),   \
-   "1"(VMWARE_PORT_CMD_##cmd), \
-   "2"(VMWARE_HYPERVISOR_PORT), "3"(UINT_MAX) :\
-   "memory");
+#define VMWARE_PORT(cmd, eax, ebx, ecx, edx) \
+({   \
+   unsigned long __si = 0, __di = 0; \
+   VMW_PORT(VMWARE_PORT_CMD_##cmd, UINT_MAX, VMWARE_HYPERVISOR_PORT, \
+VMWARE_HYPERVISOR_MAGIC, \
+eax, ebx, ecx, edx, __si, __di); \
+})
+
 
 static inline int __vmware_platform(void)
 {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/6] x86: Add VMWare Host Communication Macros

[Sinclair Yeh]

Thanks Peter.


On Tue, Dec 01, 2015 at 02:49:11PM -0800, H. Peter Anvin wrote:
> On 12/01/15 14:18, Sinclair Yeh wrote:
> > These macros will be used by multiple VMWare modules for handling
> > host communication.
> 
> > +   __asm__ __volatile__ ("inl %%dx" :  \
> 
> This is odd at best; the standard assembly form of this instruction is:
> 
>   inl (%dx),%eax

Ok, I'm not sure why this worked and compiled before.  Fixed.

> 
> Also, we don't need the underscored forms of asm and volatile for kernel
> code.
> 
> > +   __asm__ __volatile__ ("movq %13, %%rbp;"\
> > +   "cld; rep outsb; "  \
> > +   "movq %%rbp, %6" :  \
> 
> cld shouldn't be necessary here, DF=0 is part of the normal ABI environment.
> 
> You also don't save/restore %rbp here, but you do below?  Seems very odd.

Good catch.  Fixed.

> 
> It might be better do so something like:
> 
> +#define VMW_PORT_HB_OUT(in1, in2, port_num, magic, \
> + eax, ebx, ecx, edx, si, di, bp) \
> +({ \
> + __asm__ __volatile__ ("xchgq %6, %%rbp;"\
> + "cld; rep outsb; "  \
> + "xchgq %%rbp, %6" : \
> + "=a"(eax),  \
> + "=b"(ebx),  \
> + "=c"(ecx),  \
> + "=d"(edx),  \
> + "+S"(si),   \
> + "+D"(di),   \
> + "+r"(bp) :  \
> + "a"(magic), \
> + "b"(in1),   \
> + "c"(in2),   \
> + "d"(port_num) : \
> + "memory", "cc");\
> +})

This is great.  Changed.

Updated patch set incoming.

Sinclair

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Sinclair Yeh]

On Wed, Dec 02, 2015 at 10:45:28AM -0800, Greg Kroah-Hartman wrote:
> On Wed, Dec 02, 2015 at 09:26:34AM -0800, Dmitry Torokhov wrote:
> > On Wed, Dec 02, 2015 at 07:31:24AM -0800, Greg Kroah-Hartman wrote:
> > > On Tue, Dec 01, 2015 at 06:21:06PM -0800, Sinclair Yeh wrote:
> > > > On Tue, Dec 01, 2015 at 04:04:08PM -0800, Greg Kroah-Hartman wrote:
> > > > > On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Tue, Dec 01, 2015 at 02:45:27PM -0800, Dmitry Torokhov wrote:
> > > > > > > On Tue, Dec 1, 2015 at 2:32 PM, Sinclair Yeh  
> > > > > > > wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > >> >   */
> > > > > > > >> > -#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
> > > > > > > >> > -({ \
> > > > > > > >> > -   unsigned long __dummy1, __dummy2;   \
> > > > > > > >> > -   __asm__ __volatile__ ("inl %%dx" :  \
> > > > > > > >> > -   "=a"(out1), \
> > > > > > > >> > -   "=b"(out2), \
> > > > > > > >> > -   "=c"(out3), \
> > > > > > > >> > -   "=d"(out4), \
> > > > > > > >> > -   "=S"(__dummy1), \
> > > > > > > >> > -   "=D"(__dummy2) :\
> > > > > > > >> > -   "a"(VMMOUSE_PROTO_MAGIC),   \
> > > > > > > >> > -   "b"(in1),   \
> > > > > > > >> > -   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
> > > > > > > >> > -   "d"(VMMOUSE_PROTO_PORT) :   \
> > > > > > > >> > -   "memory");  \
> > > > > > > >> > +#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)   
> > > > > > > >> >   \
> > > > > > > >> > +({  
> > > > > > > >> >   \
> > > > > > > >> > +   unsigned long __dummy1 = 0, __dummy2 = 0;
> > > > > > > >> >   \
> > > > > > > >>
> > > > > > > >> Why do we need to initialize dummies?
> > > > > > > >
> > > > > > > > Because for some commands those parameters to VMW_PORT() can be 
> > > > > > > > both
> > > > > > > > input and outout.
> > > > > > > 
> > > > > > > The vmmouse commands do not use them as input though, so it seems 
> > > > > > > we
> > > > > > > are simply wasting CPU cycles setting them to 0 just because we 
> > > > > > > are
> > > > > > > using the new VMW_PORT here. Why do we need to switch? What is the
> > > > > > > benefit of doing this?
> > > > > > 
> > > > > > There are two reasons.  One is to make the code more readable and
> > > > > > maintainable.  Rather than having mostly similar inline assembly
> > > > > > code sprinkled across multiple modules, we can just use the macros
> > > > > > and document that.
> > > > > 
> > > > > But the macro is only used here, and the variables aren't used at all,
> > > > > so it makes no sense in this file.
> > > > 
> > > > Maybe it's because I didn't CC you on the rest of the series.  I wasn't
> > > > sure what the proper distribution list is for each part.
> > > 
> > > Use scripts/get_maintainer.pl, that's what it is there for.  A number of
> > > those patches should go through me, if not all of them, if you want them
> > > merged...
> > > 
> &

Re: [PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Sinclair Yeh]

On Wed, Dec 02, 2015 at 07:31:24AM -0800, Greg Kroah-Hartman wrote:
> On Tue, Dec 01, 2015 at 06:21:06PM -0800, Sinclair Yeh wrote:
> > On Tue, Dec 01, 2015 at 04:04:08PM -0800, Greg Kroah-Hartman wrote:
> > > On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote:
> > > > Hi,
> > > > 
> > > > On Tue, Dec 01, 2015 at 02:45:27PM -0800, Dmitry Torokhov wrote:
> > > > > On Tue, Dec 1, 2015 at 2:32 PM, Sinclair Yeh  wrote:
> > > > > > Hi,
> > > > > >
> > > > 
> > > > 
> > > > 
> > > > > >> >   */
> > > > > >> > -#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
> > > > > >> > -({ \
> > > > > >> > -   unsigned long __dummy1, __dummy2;   \
> > > > > >> > -   __asm__ __volatile__ ("inl %%dx" :  \
> > > > > >> > -   "=a"(out1), \
> > > > > >> > -   "=b"(out2), \
> > > > > >> > -   "=c"(out3), \
> > > > > >> > -   "=d"(out4), \
> > > > > >> > -   "=S"(__dummy1), \
> > > > > >> > -   "=D"(__dummy2) :\
> > > > > >> > -   "a"(VMMOUSE_PROTO_MAGIC),   \
> > > > > >> > -   "b"(in1),   \
> > > > > >> > -   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
> > > > > >> > -   "d"(VMMOUSE_PROTO_PORT) :   \
> > > > > >> > -   "memory");  \
> > > > > >> > +#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)   
> > > > > >> >   \
> > > > > >> > +({\
> > > > > >> > +   unsigned long __dummy1 = 0, __dummy2 = 0;  \
> > > > > >>
> > > > > >> Why do we need to initialize dummies?
> > > > > >
> > > > > > Because for some commands those parameters to VMW_PORT() can be both
> > > > > > input and outout.
> > > > > 
> > > > > The vmmouse commands do not use them as input though, so it seems we
> > > > > are simply wasting CPU cycles setting them to 0 just because we are
> > > > > using the new VMW_PORT here. Why do we need to switch? What is the
> > > > > benefit of doing this?
> > > > 
> > > > There are two reasons.  One is to make the code more readable and
> > > > maintainable.  Rather than having mostly similar inline assembly
> > > > code sprinkled across multiple modules, we can just use the macros
> > > > and document that.
> > > 
> > > But the macro is only used here, and the variables aren't used at all,
> > > so it makes no sense in this file.
> > 
> > Maybe it's because I didn't CC you on the rest of the series.  I wasn't
> > sure what the proper distribution list is for each part.
> 
> Use scripts/get_maintainer.pl, that's what it is there for.  A number of
> those patches should go through me, if not all of them, if you want them
> merged...
> 
> > 
> > This new macro is also used in arch/x86/kernel/cpu/vmware.c and
> > vmw_balloon.c
> 
> And it's used inconsistantly in those patches (you don't set the dummy
> variables to 0 in all of them...)  Now maybe that's just how the asm
> functions work, but it's not very obvious as to why this is at all.
> 
> > > > The second reason is this organization makes some on-going future
> > > > development easier.
> > > 
> > > We don't plan for "future" development other than a single patch series,
> > > as we have no idea what that development is, nor if it will really
> > > happen.  You can always change this file later if you need to, nothing
> > > is keeping that from happening.
> > 
> > So the intent of this series is to centralize similar lines of inline
> > assembly code that are currently used by 3 different kernel modules
> > to a central place.  The new vmware.h [patch 0/6] becomes the one header
> > to include for common guest-host communication needs.
> 
> Why can't it go into vmw_vmci_defs.h instead, or your other .h file, why
> create yet-another-.h-file for your bus?  You already have 2, this would
> make it 3, which seems like a lot...

Ok, thanks.  Let me see if it make sense to use one of the existing 2
files.  Either way, I'll respin this series to include all the comments
so far.

> 
> thanks,
> 
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Sinclair Yeh]

On Wed, Dec 02, 2015 at 07:31:24AM -0800, Greg Kroah-Hartman wrote:
> On Tue, Dec 01, 2015 at 06:21:06PM -0800, Sinclair Yeh wrote:
> > On Tue, Dec 01, 2015 at 04:04:08PM -0800, Greg Kroah-Hartman wrote:
> > > On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote:
> > > > Hi,
> > > > 
> > > > On Tue, Dec 01, 2015 at 02:45:27PM -0800, Dmitry Torokhov wrote:
> > > > > On Tue, Dec 1, 2015 at 2:32 PM, Sinclair Yeh <s...@vmware.com> wrote:
> > > > > > Hi,
> > > > > >
> > > > 
> > > > 
> > > > 
> > > > > >> >   */
> > > > > >> > -#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
> > > > > >> > -({ \
> > > > > >> > -   unsigned long __dummy1, __dummy2;   \
> > > > > >> > -   __asm__ __volatile__ ("inl %%dx" :  \
> > > > > >> > -   "=a"(out1), \
> > > > > >> > -   "=b"(out2), \
> > > > > >> > -   "=c"(out3), \
> > > > > >> > -   "=d"(out4), \
> > > > > >> > -   "=S"(__dummy1), \
> > > > > >> > -   "=D"(__dummy2) :\
> > > > > >> > -   "a"(VMMOUSE_PROTO_MAGIC),   \
> > > > > >> > -   "b"(in1),   \
> > > > > >> > -   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
> > > > > >> > -   "d"(VMMOUSE_PROTO_PORT) :   \
> > > > > >> > -   "memory");  \
> > > > > >> > +#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)   
> > > > > >> >   \
> > > > > >> > +({\
> > > > > >> > +   unsigned long __dummy1 = 0, __dummy2 = 0;  \
> > > > > >>
> > > > > >> Why do we need to initialize dummies?
> > > > > >
> > > > > > Because for some commands those parameters to VMW_PORT() can be both
> > > > > > input and outout.
> > > > > 
> > > > > The vmmouse commands do not use them as input though, so it seems we
> > > > > are simply wasting CPU cycles setting them to 0 just because we are
> > > > > using the new VMW_PORT here. Why do we need to switch? What is the
> > > > > benefit of doing this?
> > > > 
> > > > There are two reasons.  One is to make the code more readable and
> > > > maintainable.  Rather than having mostly similar inline assembly
> > > > code sprinkled across multiple modules, we can just use the macros
> > > > and document that.
> > > 
> > > But the macro is only used here, and the variables aren't used at all,
> > > so it makes no sense in this file.
> > 
> > Maybe it's because I didn't CC you on the rest of the series.  I wasn't
> > sure what the proper distribution list is for each part.
> 
> Use scripts/get_maintainer.pl, that's what it is there for.  A number of
> those patches should go through me, if not all of them, if you want them
> merged...
> 
> > 
> > This new macro is also used in arch/x86/kernel/cpu/vmware.c and
> > vmw_balloon.c
> 
> And it's used inconsistantly in those patches (you don't set the dummy
> variables to 0 in all of them...)  Now maybe that's just how the asm
> functions work, but it's not very obvious as to why this is at all.
> 
> > > > The second reason is this organization makes some on-going future
> > > > development easier.
> > > 
> > > We don't plan for "future" development other than a single patch series,
> > > as we have no idea what that development is, nor if it will really
> > > happen.  You can always change this file later if you need to, nothing
> > > is keeping that from happening.
> > 
> > So the intent of this series is to centralize similar lines of inline
> > assembly code that are currently used by 3 different kernel modules
> > to a central place.  The new vmware.h [patch 0/6] becomes the one header
> > to include for common guest-host communication needs.
> 
> Why can't it go into vmw_vmci_defs.h instead, or your other .h file, why
> create yet-another-.h-file for your bus?  You already have 2, this would
> make it 3, which seems like a lot...

Ok, thanks.  Let me see if it make sense to use one of the existing 2
files.  Either way, I'll respin this series to include all the comments
so far.

> 
> thanks,
> 
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Sinclair Yeh]

On Wed, Dec 02, 2015 at 10:45:28AM -0800, Greg Kroah-Hartman wrote:
> On Wed, Dec 02, 2015 at 09:26:34AM -0800, Dmitry Torokhov wrote:
> > On Wed, Dec 02, 2015 at 07:31:24AM -0800, Greg Kroah-Hartman wrote:
> > > On Tue, Dec 01, 2015 at 06:21:06PM -0800, Sinclair Yeh wrote:
> > > > On Tue, Dec 01, 2015 at 04:04:08PM -0800, Greg Kroah-Hartman wrote:
> > > > > On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Tue, Dec 01, 2015 at 02:45:27PM -0800, Dmitry Torokhov wrote:
> > > > > > > On Tue, Dec 1, 2015 at 2:32 PM, Sinclair Yeh <s...@vmware.com> 
> > > > > > > wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > >> >   */
> > > > > > > >> > -#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
> > > > > > > >> > -({ \
> > > > > > > >> > -   unsigned long __dummy1, __dummy2;   \
> > > > > > > >> > -   __asm__ __volatile__ ("inl %%dx" :  \
> > > > > > > >> > -   "=a"(out1), \
> > > > > > > >> > -   "=b"(out2), \
> > > > > > > >> > -   "=c"(out3), \
> > > > > > > >> > -   "=d"(out4), \
> > > > > > > >> > -   "=S"(__dummy1), \
> > > > > > > >> > -   "=D"(__dummy2) :\
> > > > > > > >> > -   "a"(VMMOUSE_PROTO_MAGIC),   \
> > > > > > > >> > -   "b"(in1),   \
> > > > > > > >> > -   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
> > > > > > > >> > -   "d"(VMMOUSE_PROTO_PORT) :   \
> > > > > > > >> > -   "memory");  \
> > > > > > > >> > +#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)   
> > > > > > > >> >   \
> > > > > > > >> > +({  
> > > > > > > >> >   \
> > > > > > > >> > +   unsigned long __dummy1 = 0, __dummy2 = 0;
> > > > > > > >> >   \
> > > > > > > >>
> > > > > > > >> Why do we need to initialize dummies?
> > > > > > > >
> > > > > > > > Because for some commands those parameters to VMW_PORT() can be 
> > > > > > > > both
> > > > > > > > input and outout.
> > > > > > > 
> > > > > > > The vmmouse commands do not use them as input though, so it seems 
> > > > > > > we
> > > > > > > are simply wasting CPU cycles setting them to 0 just because we 
> > > > > > > are
> > > > > > > using the new VMW_PORT here. Why do we need to switch? What is the
> > > > > > > benefit of doing this?
> > > > > > 
> > > > > > There are two reasons.  One is to make the code more readable and
> > > > > > maintainable.  Rather than having mostly similar inline assembly
> > > > > > code sprinkled across multiple modules, we can just use the macros
> > > > > > and document that.
> > > > > 
> > > > > But the macro is only used here, and the variables aren't used at all,
> > > > > so it makes no sense in this file.
> > > > 
> > > > Maybe it's because I didn't CC you on the rest of the series.  I wasn't
> > > > sure what the proper distribution list is for each part.
> > > 
> > > Use scripts/get_maintainer.pl, that's what it is there for.  A number of
> > > those patches should go through me, if not all of them, if you want them
> > > merged...
> &g

Re: [PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Sinclair Yeh]

On Tue, Dec 01, 2015 at 04:04:08PM -0800, Greg Kroah-Hartman wrote:
> On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote:
> > Hi,
> > 
> > On Tue, Dec 01, 2015 at 02:45:27PM -0800, Dmitry Torokhov wrote:
> > > On Tue, Dec 1, 2015 at 2:32 PM, Sinclair Yeh  wrote:
> > > > Hi,
> > > >
> > 
> > 
> > 
> > > >> >   */
> > > >> > -#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
> > > >> > -({ \
> > > >> > -   unsigned long __dummy1, __dummy2;   \
> > > >> > -   __asm__ __volatile__ ("inl %%dx" :  \
> > > >> > -   "=a"(out1), \
> > > >> > -   "=b"(out2), \
> > > >> > -   "=c"(out3), \
> > > >> > -   "=d"(out4), \
> > > >> > -   "=S"(__dummy1), \
> > > >> > -   "=D"(__dummy2) :\
> > > >> > -   "a"(VMMOUSE_PROTO_MAGIC),   \
> > > >> > -   "b"(in1),   \
> > > >> > -   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
> > > >> > -   "d"(VMMOUSE_PROTO_PORT) :   \
> > > >> > -   "memory");  \
> > > >> > +#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)   
> > > >> >   \
> > > >> > +({\
> > > >> > +   unsigned long __dummy1 = 0, __dummy2 = 0;  \
> > > >>
> > > >> Why do we need to initialize dummies?
> > > >
> > > > Because for some commands those parameters to VMW_PORT() can be both
> > > > input and outout.
> > > 
> > > The vmmouse commands do not use them as input though, so it seems we
> > > are simply wasting CPU cycles setting them to 0 just because we are
> > > using the new VMW_PORT here. Why do we need to switch? What is the
> > > benefit of doing this?
> > 
> > There are two reasons.  One is to make the code more readable and
> > maintainable.  Rather than having mostly similar inline assembly
> > code sprinkled across multiple modules, we can just use the macros
> > and document that.
> 
> But the macro is only used here, and the variables aren't used at all,
> so it makes no sense in this file.

Maybe it's because I didn't CC you on the rest of the series.  I wasn't
sure what the proper distribution list is for each part.

This new macro is also used in arch/x86/kernel/cpu/vmware.c and
vmw_balloon.c


> 
> > The second reason is this organization makes some on-going future
> > development easier.
> 
> We don't plan for "future" development other than a single patch series,
> as we have no idea what that development is, nor if it will really
> happen.  You can always change this file later if you need to, nothing
> is keeping that from happening.

So the intent of this series is to centralize similar lines of inline
assembly code that are currently used by 3 different kernel modules
to a central place.  The new vmware.h [patch 0/6] becomes the one header
to include for common guest-host communication needs.


> thanks,
> 
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/6] VMware balloon: Update vmw_balloon.c to use the VMW_PORT macro

[Sinclair Yeh]

Thanks!  Done.

On Tue, Dec 01, 2015 at 02:38:01PM -0800, Xavier Deguillard wrote:
> Hey Sinclair,
> 
> On Tue, Dec 01, 2015 at 02:18:52PM -0800, Sinclair Yeh wrote:
> > +#define VMWARE_BALLOON_CMD(cmd, data, result) \
> > +({\
> > +   unsigned long __status, __dummy1, __dummy2;\
> > +   unsigned long __si = 0, __di = 0;  \
> > +   VMW_PORT(data, VMW_BALLOON_CMD_##cmd, VMW_BALLOON_HV_PORT, \
> > +VMW_BALLOON_HV_MAGIC, \
> > +__status, result, __dummy1, __dummy2, __si, __di);\
> > +   if (VMW_BALLOON_CMD_##cmd == VMW_BALLOON_CMD_START)\
> > +   result = __dummy1; \
> > +   result &= -1UL;\
> > +   __status & -1UL;   \
> >  })
> 
> You need to indent the '\' with tabs only, and it looks like spaces are
> present here (which is also why they don't look aligned).
> 
> Other than that I'm good with this:
> 
> Acked-by: Xavier Deguillard 
> 
> Xavier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] Input: Remove vmmouse port reservation

[Sinclair Yeh]

Hi,

On Tue, Dec 01, 2015 at 02:30:05PM -0800, Dmitry Torokhov wrote:
> Hi Sinclair,
> 
> On Tue, Dec 1, 2015 at 2:18 PM, Sinclair Yeh  wrote:
> > Port reservation is not required.
> 
> You need to expand on why we do not need to reserve port.

Thomas gave me this input earlier, too, so I added the one liner.

There was a long discussion on accessing the port a few years ago:
https://lkml.org/lkml/2008/9/24/512

> 
> > Furthermore, this port is shared
> > by other VMware services for host-side communication.
> 
> What services would that be? Do they reserve the port?

This port is used by quite a few guest-to-host communication capabilities,
e.g. getting configuration, logging, etc.  Currently multiple kernel
modules, and one or more priviledged guest user mode app, e.g.
open-vmware-tools, use this port without reservation.

After some internal discussions, it was determined that no reservation
is required when accessing the port in this manner.

Do you want me to put the above in the commit message?

> 
> Thanks.
> 
> -- 
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Sinclair Yeh]

Hi,

On Tue, Dec 01, 2015 at 02:45:27PM -0800, Dmitry Torokhov wrote:
> On Tue, Dec 1, 2015 at 2:32 PM, Sinclair Yeh  wrote:
> > Hi,
> >



> >> >   */
> >> > -#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
> >> > -({ \
> >> > -   unsigned long __dummy1, __dummy2;   \
> >> > -   __asm__ __volatile__ ("inl %%dx" :  \
> >> > -   "=a"(out1), \
> >> > -   "=b"(out2), \
> >> > -   "=c"(out3), \
> >> > -   "=d"(out4), \
> >> > -   "=S"(__dummy1), \
> >> > -   "=D"(__dummy2) :\
> >> > -   "a"(VMMOUSE_PROTO_MAGIC),   \
> >> > -   "b"(in1),   \
> >> > -   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
> >> > -   "d"(VMMOUSE_PROTO_PORT) :   \
> >> > -   "memory");  \
> >> > +#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4) \
> >> > +({\
> >> > +   unsigned long __dummy1 = 0, __dummy2 = 0;  \
> >>
> >> Why do we need to initialize dummies?
> >
> > Because for some commands those parameters to VMW_PORT() can be both
> > input and outout.
> 
> The vmmouse commands do not use them as input though, so it seems we
> are simply wasting CPU cycles setting them to 0 just because we are
> using the new VMW_PORT here. Why do we need to switch? What is the
> benefit of doing this?

There are two reasons.  One is to make the code more readable and
maintainable.  Rather than having mostly similar inline assembly
code sprinkled across multiple modules, we can just use the macros
and document that.

The second reason is this organization makes some on-going future
development easier.

Hope this helps.

Sinclair
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Sinclair Yeh]

Hi,

On Tue, Dec 01, 2015 at 02:24:14PM -0800, Dmitry Torokhov wrote:
> On Tue, Dec 01, 2015 at 02:18:49PM -0800, Sinclair Yeh wrote:
> > v2:
> > Instead of replacing existing VMMOUSE defines, only modify enough
> > to use the new VMW_PORT define.
> > 
> > v3:
> > Use updated VMWARE_PORT() which requires hypervisor magic as an added
> > parameter
> > 
> > Signed-off-by: Sinclair Yeh 
> > Reviewed-by: Thomas Hellstrom 
> > Reviewed-by: Alok N Kataria 
> > Cc: pv-driv...@vmware.com
> > Cc: linux-graphics-maintai...@vmware.com
> > Cc: Dmitry Torokhov 
> > Cc: Arnd Bergmann 
> > Cc: Greg Kroah-Hartman 
> > Cc: linux-kernel@vger.kernel.org
> > Cc: virtualizat...@lists.linux-foundation.org
> > Cc: linux-in...@vger.kernel.org
> > ---
> >  drivers/input/mouse/vmmouse.c | 22 +++---
> >  1 file changed, 7 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
> > index e272f06..d34e3e4 100644
> > --- a/drivers/input/mouse/vmmouse.c
> > +++ b/drivers/input/mouse/vmmouse.c
> > @@ -19,6 +19,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include "psmouse.h"
> >  #include "vmmouse.h"
> > @@ -84,21 +85,12 @@ struct vmmouse_data {
> >   * implementing the vmmouse protocol. Should never execute on
> >   * bare metal hardware.
> >   */
> > -#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
> > -({ \
> > -   unsigned long __dummy1, __dummy2;   \
> > -   __asm__ __volatile__ ("inl %%dx" :  \
> > -   "=a"(out1), \
> > -   "=b"(out2), \
> > -   "=c"(out3), \
> > -   "=d"(out4), \
> > -   "=S"(__dummy1), \
> > -   "=D"(__dummy2) :\
> > -   "a"(VMMOUSE_PROTO_MAGIC),   \
> > -   "b"(in1),   \
> > -   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
> > -   "d"(VMMOUSE_PROTO_PORT) :   \
> > -   "memory");  \
> > +#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4) \
> > +({\
> > +   unsigned long __dummy1 = 0, __dummy2 = 0;  \
> 
> Why do we need to initialize dummies?

Because for some commands those parameters to VMW_PORT() can be both
input and outout.  So it's safer to initialize them to 0.  Since
they can potentially be an output, we can't make them a constant.

> 
> > +   VMW_PORT(in1, VMMOUSE_PROTO_CMD_##cmd, VMMOUSE_PROTO_PORT, \
> > +VMMOUSE_PROTO_MAGIC,  \
> > +out1, out2, out3, out4, __dummy1, __dummy2);  \
> >  })
> >  
> 
> Thanks.
> 
> -- 
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/6] x86: Update vmware.c to use the common VMW_PORT macros

[Sinclair Yeh]

v2:
Instead of replacing all existing instances of VMWARE_PORT
with VMW_PORT, update VMWARE_PORT to use the new VMW_PORT.

v3:
Using updated VMWARE_PORT() macro, which needs hypervisor magic in the
parameter

Signed-off-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
Reviewed-by: Alok N Kataria 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: pv-driv...@vmware.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
---
 arch/x86/kernel/cpu/vmware.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 628a059..1837f66 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define CPUID_VMWARE_INFO_LEAF 0x4000
 #define VMWARE_HYPERVISOR_MAGIC0x564D5868
@@ -37,13 +38,14 @@
 #define VMWARE_PORT_CMD_LEGACY_X2APIC  3
 #define VMWARE_PORT_CMD_VCPU_RESERVED  31
 
-#define VMWARE_PORT(cmd, eax, ebx, ecx, edx)   \
-   __asm__("inl (%%dx)" :  \
-   "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) :\
-   "0"(VMWARE_HYPERVISOR_MAGIC),   \
-   "1"(VMWARE_PORT_CMD_##cmd), \
-   "2"(VMWARE_HYPERVISOR_PORT), "3"(UINT_MAX) :\
-   "memory");
+#define VMWARE_PORT(cmd, eax, ebx, ecx, edx) \
+({   \
+   unsigned long __si = 0, __di = 0; \
+   VMW_PORT(UINT_MAX, VMWARE_PORT_CMD_##cmd, VMWARE_HYPERVISOR_PORT, \
+VMWARE_HYPERVISOR_MAGIC, \
+eax, ebx, ecx, edx, __si, __di); \
+})
+
 
 static inline int __vmware_platform(void)
 {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Sinclair Yeh]

v2:
Instead of replacing existing VMMOUSE defines, only modify enough
to use the new VMW_PORT define.

v3:
Use updated VMWARE_PORT() which requires hypervisor magic as an added
parameter

Signed-off-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
Reviewed-by: Alok N Kataria 
Cc: pv-driv...@vmware.com
Cc: linux-graphics-maintai...@vmware.com
Cc: Dmitry Torokhov 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-in...@vger.kernel.org
---
 drivers/input/mouse/vmmouse.c | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
index e272f06..d34e3e4 100644
--- a/drivers/input/mouse/vmmouse.c
+++ b/drivers/input/mouse/vmmouse.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "psmouse.h"
 #include "vmmouse.h"
@@ -84,21 +85,12 @@ struct vmmouse_data {
  * implementing the vmmouse protocol. Should never execute on
  * bare metal hardware.
  */
-#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
-({ \
-   unsigned long __dummy1, __dummy2;   \
-   __asm__ __volatile__ ("inl %%dx" :  \
-   "=a"(out1), \
-   "=b"(out2), \
-   "=c"(out3), \
-   "=d"(out4), \
-   "=S"(__dummy1), \
-   "=D"(__dummy2) :\
-   "a"(VMMOUSE_PROTO_MAGIC),   \
-   "b"(in1),   \
-   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
-   "d"(VMMOUSE_PROTO_PORT) :   \
-   "memory");  \
+#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4) \
+({\
+   unsigned long __dummy1 = 0, __dummy2 = 0;  \
+   VMW_PORT(in1, VMMOUSE_PROTO_CMD_##cmd, VMMOUSE_PROTO_PORT, \
+VMMOUSE_PROTO_MAGIC,  \
+out1, out2, out3, out4, __dummy1, __dummy2);  \
 })
 
 /**
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/6] x86: Remove address from the vmware.c header

[Sinclair Yeh]

We should no longer have mailing address of Free Software
Foundation in the copyright header.  Since this patch series
touches this file, taking this opportunity to fix the header.

Signed-off-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
Reviewed-by: Alok N Kataria 
Cc: pv-driv...@vmware.com
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
---
 arch/x86/kernel/cpu/vmware.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 1837f66..850a940 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -15,10 +15,6 @@
  * NON INFRINGEMENT.  See the GNU General Public License for more
  * details.
  *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
- *
  */
 
 #include 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/6] Input: Remove vmmouse port reservation

[Sinclair Yeh]

Port reservation is not required.  Furthermore, this port is shared
by other VMware services for host-side communication.

Signed-off-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
Cc: pv-driv...@vmware.com
Cc: linux-graphics-maintai...@vmware.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/input/mouse/vmmouse.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
index d34e3e4..9109d54 100644
--- a/drivers/input/mouse/vmmouse.c
+++ b/drivers/input/mouse/vmmouse.c
@@ -347,16 +347,10 @@ int vmmouse_detect(struct psmouse *psmouse, bool 
set_properties)
return -ENXIO;
}
 
-   if (!request_region(VMMOUSE_PROTO_PORT, 4, "vmmouse")) {
-   psmouse_dbg(psmouse, "VMMouse port in use.\n");
-   return -EBUSY;
-   }
-
/* Check if the device is present */
response = ~VMMOUSE_PROTO_MAGIC;
VMMOUSE_CMD(GETVERSION, 0, version, response, dummy1, dummy2);
if (response != VMMOUSE_PROTO_MAGIC || version == 0xU) {
-   release_region(VMMOUSE_PROTO_PORT, 4);
return -ENXIO;
}
 
@@ -366,8 +360,6 @@ int vmmouse_detect(struct psmouse *psmouse, bool 
set_properties)
psmouse->model = version;
}
 
-   release_region(VMMOUSE_PROTO_PORT, 4);
-
return 0;
 }
 
@@ -386,7 +378,6 @@ static void vmmouse_disconnect(struct psmouse *psmouse)
psmouse_reset(psmouse);
input_unregister_device(priv->abs_dev);
kfree(priv);
-   release_region(VMMOUSE_PROTO_PORT, 4);
 }
 
 /**
@@ -430,15 +421,10 @@ int vmmouse_init(struct psmouse *psmouse)
struct input_dev *rel_dev = psmouse->dev, *abs_dev;
int error;
 
-   if (!request_region(VMMOUSE_PROTO_PORT, 4, "vmmouse")) {
-   psmouse_dbg(psmouse, "VMMouse port in use.\n");
-   return -EBUSY;
-   }
-
psmouse_reset(psmouse);
error = vmmouse_enable(psmouse);
if (error)
-   goto release_region;
+   return error;
 
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
abs_dev = input_allocate_device();
@@ -493,8 +479,5 @@ init_fail:
kfree(priv);
psmouse->private = NULL;
 
-release_region:
-   release_region(VMMOUSE_PROTO_PORT, 4);
-
return error;
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/6] VMware balloon: Update vmw_balloon.c to use the VMW_PORT macro

[Sinclair Yeh]

Signed-off-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
Reviewed-by: Alok N Kataria 
Cc: pv-driv...@vmware.com
Cc: Xavier Deguillard 
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
---
 drivers/misc/vmw_balloon.c | 29 -
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
index ffb5634..90a0d07 100644
--- a/drivers/misc/vmw_balloon.c
+++ b/drivers/misc/vmw_balloon.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_AUTHOR("VMware, Inc.");
 MODULE_DESCRIPTION("VMware Memory Control (Balloon) Driver");
@@ -142,23 +143,17 @@ enum vmwballoon_capabilities {
 
 #define VMW_BALLOON_SUCCESS_WITH_CAPABILITIES  (0x0300)
 
-#define VMWARE_BALLOON_CMD(cmd, data, result)  \
-({ \
-   unsigned long __status, __dummy1, __dummy2; \
-   __asm__ __volatile__ ("inl %%dx" :  \
-   "=a"(__status), \
-   "=c"(__dummy1), \
-   "=d"(__dummy2), \
-   "=b"(result) :  \
-   "0"(VMW_BALLOON_HV_MAGIC),  \
-   "1"(VMW_BALLOON_CMD_##cmd), \
-   "2"(VMW_BALLOON_HV_PORT),   \
-   "3"(data) : \
-   "memory");  \
-   if (VMW_BALLOON_CMD_##cmd == VMW_BALLOON_CMD_START) \
-   result = __dummy1;  \
-   result &= -1UL; \
-   __status & -1UL;\
+#define VMWARE_BALLOON_CMD(cmd, data, result) \
+({\
+   unsigned long __status, __dummy1, __dummy2;\
+   unsigned long __si = 0, __di = 0;  \
+   VMW_PORT(data, VMW_BALLOON_CMD_##cmd, VMW_BALLOON_HV_PORT, \
+VMW_BALLOON_HV_MAGIC, \
+__status, result, __dummy1, __dummy2, __si, __di);\
+   if (VMW_BALLOON_CMD_##cmd == VMW_BALLOON_CMD_START)\
+   result = __dummy1; \
+   result &= -1UL;\
+   __status & -1UL;   \
 })
 
 #ifdef CONFIG_DEBUG_FS
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/6] x86: Add VMWare Host Communication Macros

[Sinclair Yeh]

These macros will be used by multiple VMWare modules for handling
host communication.

v2:
* Keeping only the minimal common platform defines
* added vmware_platform() check function

v3:
* Added new field to handle different hypervisor magic values

Signed-off-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
Reviewed-by: Alok N Kataria 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Alok Kataria 
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: Xavier Deguillard 
---
 arch/x86/include/asm/vmware.h | 110 ++
 1 file changed, 110 insertions(+)
 create mode 100644 arch/x86/include/asm/vmware.h

diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
new file mode 100644
index 000..32bf99b
--- /dev/null
+++ b/arch/x86/include/asm/vmware.h
@@ -0,0 +1,110 @@
+/*
+ * Copyright (C) 2015, VMware, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT.  See the GNU General Public License for more
+ * details.
+ *
+ * Based on code from vmware.c and vmmouse.c.
+ * Author:
+ *   Sinclair Yeh 
+ */
+#ifndef _ASM_X86_VMWARE_H
+#define _ASM_X86_VMWARE_H
+
+
+/**
+ * Hypervisor-specific bi-directional communication channel.  Should never
+ * execute on bare metal hardware.  The caller must make sure to check for
+ * supported hypervisor before using these macros.
+ *
+ * Several of the parameters are both input and output and must be initialized.
+ *
+ * @in1: [IN] Message Len or Message Cmd (HB)
+ * @in2: [IN] Message Len (HB) or Message Cmd
+ * @port_num: [IN] port number + [channel id]
+ * @magic: [IN] hypervisor magic value
+ * @eax: [OUT] value of EAX register
+ * @ebx: [OUT] e.g. status from an HB message status command
+ * @ecx: [OUT] e.g. status from a non-HB message status command
+ * @edx: [OUT] e.g. channel id
+ * @si: [INOUT] set to 0 if not used
+ * @di: [INOUT] set to 0 if not used
+ * @bp: [INOUT] set to 0 if not used
+ */
+#define VMW_PORT(in1, in2, port_num, magic, eax, ebx, ecx, edx, si, di) \
+({  \
+   __asm__ __volatile__ ("inl %%dx" :  \
+   "=a"(eax),  \
+   "=b"(ebx),  \
+   "=c"(ecx),  \
+   "=d"(edx),  \
+   "=S"(si),   \
+   "=D"(di) :  \
+   "a"(magic), \
+   "b"(in1),   \
+   "c"(in2),   \
+   "d"(port_num),  \
+   "S"(si),\
+   "D"(di) :   \
+   "memory");  \
+})
+
+
+#define VMW_PORT_HB_OUT(in1, in2, port_num, magic,  \
+   eax, ebx, ecx, edx, si, di, bp) \
+({  \
+   __asm__ __volatile__ ("movq %13, %%rbp;"\
+   "cld; rep outsb; "  \
+   "movq %%rbp, %6" :  \
+   "=a"(eax),  \
+   "=b"(ebx),  \
+   "=c"(ecx),  \
+   "=d"(edx),  \
+   "=S"(si),   \
+   "=D"(di),   \
+   "=r"(bp) :  \
+   "a"(magic), \
+   "b"(in1),   \
+   "c"(in2),   \
+   "d"(port_num),  \
+   "S"(si),\

[PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Sinclair Yeh]

v2:
Instead of replacing existing VMMOUSE defines, only modify enough
to use the new VMW_PORT define.

v3:
Use updated VMWARE_PORT() which requires hypervisor magic as an added
parameter

Signed-off-by: Sinclair Yeh <s...@vmware.com>
Reviewed-by: Thomas Hellstrom <thellst...@vmware.com>
Reviewed-by: Alok N Kataria <akata...@vmware.com>
Cc: pv-driv...@vmware.com
Cc: linux-graphics-maintai...@vmware.com
Cc: Dmitry Torokhov <dmitry.torok...@gmail.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-in...@vger.kernel.org
---
 drivers/input/mouse/vmmouse.c | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
index e272f06..d34e3e4 100644
--- a/drivers/input/mouse/vmmouse.c
+++ b/drivers/input/mouse/vmmouse.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "psmouse.h"
 #include "vmmouse.h"
@@ -84,21 +85,12 @@ struct vmmouse_data {
  * implementing the vmmouse protocol. Should never execute on
  * bare metal hardware.
  */
-#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
-({ \
-   unsigned long __dummy1, __dummy2;   \
-   __asm__ __volatile__ ("inl %%dx" :  \
-   "=a"(out1), \
-   "=b"(out2), \
-   "=c"(out3), \
-   "=d"(out4), \
-   "=S"(__dummy1), \
-   "=D"(__dummy2) :\
-   "a"(VMMOUSE_PROTO_MAGIC),   \
-   "b"(in1),   \
-   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
-   "d"(VMMOUSE_PROTO_PORT) :   \
-   "memory");  \
+#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4) \
+({\
+   unsigned long __dummy1 = 0, __dummy2 = 0;  \
+   VMW_PORT(in1, VMMOUSE_PROTO_CMD_##cmd, VMMOUSE_PROTO_PORT, \
+VMMOUSE_PROTO_MAGIC,  \
+out1, out2, out3, out4, __dummy1, __dummy2);  \
 })
 
 /**
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/6] x86: Update vmware.c to use the common VMW_PORT macros

[Sinclair Yeh]

v2:
Instead of replacing all existing instances of VMWARE_PORT
with VMW_PORT, update VMWARE_PORT to use the new VMW_PORT.

v3:
Using updated VMWARE_PORT() macro, which needs hypervisor magic in the
parameter

Signed-off-by: Sinclair Yeh <s...@vmware.com>
Reviewed-by: Thomas Hellstrom <thellst...@vmware.com>
Reviewed-by: Alok N Kataria <akata...@vmware.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: pv-driv...@vmware.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
---
 arch/x86/kernel/cpu/vmware.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 628a059..1837f66 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define CPUID_VMWARE_INFO_LEAF 0x4000
 #define VMWARE_HYPERVISOR_MAGIC0x564D5868
@@ -37,13 +38,14 @@
 #define VMWARE_PORT_CMD_LEGACY_X2APIC  3
 #define VMWARE_PORT_CMD_VCPU_RESERVED  31
 
-#define VMWARE_PORT(cmd, eax, ebx, ecx, edx)   \
-   __asm__("inl (%%dx)" :  \
-   "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) :\
-   "0"(VMWARE_HYPERVISOR_MAGIC),   \
-   "1"(VMWARE_PORT_CMD_##cmd), \
-   "2"(VMWARE_HYPERVISOR_PORT), "3"(UINT_MAX) :\
-   "memory");
+#define VMWARE_PORT(cmd, eax, ebx, ecx, edx) \
+({   \
+   unsigned long __si = 0, __di = 0; \
+   VMW_PORT(UINT_MAX, VMWARE_PORT_CMD_##cmd, VMWARE_HYPERVISOR_PORT, \
+VMWARE_HYPERVISOR_MAGIC, \
+eax, ebx, ecx, edx, __si, __di); \
+})
+
 
 static inline int __vmware_platform(void)
 {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/6] VMware balloon: Update vmw_balloon.c to use the VMW_PORT macro

[Sinclair Yeh]

Signed-off-by: Sinclair Yeh <s...@vmware.com>
Reviewed-by: Thomas Hellstrom <thellst...@vmware.com>
Reviewed-by: Alok N Kataria <akata...@vmware.com>
Cc: pv-driv...@vmware.com
Cc: Xavier Deguillard <xdeguill...@vmware.com>
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
---
 drivers/misc/vmw_balloon.c | 29 -
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
index ffb5634..90a0d07 100644
--- a/drivers/misc/vmw_balloon.c
+++ b/drivers/misc/vmw_balloon.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_AUTHOR("VMware, Inc.");
 MODULE_DESCRIPTION("VMware Memory Control (Balloon) Driver");
@@ -142,23 +143,17 @@ enum vmwballoon_capabilities {
 
 #define VMW_BALLOON_SUCCESS_WITH_CAPABILITIES  (0x0300)
 
-#define VMWARE_BALLOON_CMD(cmd, data, result)  \
-({ \
-   unsigned long __status, __dummy1, __dummy2; \
-   __asm__ __volatile__ ("inl %%dx" :  \
-   "=a"(__status), \
-   "=c"(__dummy1), \
-   "=d"(__dummy2), \
-   "=b"(result) :  \
-   "0"(VMW_BALLOON_HV_MAGIC),  \
-   "1"(VMW_BALLOON_CMD_##cmd), \
-   "2"(VMW_BALLOON_HV_PORT),   \
-   "3"(data) : \
-   "memory");  \
-   if (VMW_BALLOON_CMD_##cmd == VMW_BALLOON_CMD_START) \
-   result = __dummy1;  \
-   result &= -1UL; \
-   __status & -1UL;\
+#define VMWARE_BALLOON_CMD(cmd, data, result) \
+({\
+   unsigned long __status, __dummy1, __dummy2;\
+   unsigned long __si = 0, __di = 0;  \
+   VMW_PORT(data, VMW_BALLOON_CMD_##cmd, VMW_BALLOON_HV_PORT, \
+VMW_BALLOON_HV_MAGIC, \
+__status, result, __dummy1, __dummy2, __si, __di);\
+   if (VMW_BALLOON_CMD_##cmd == VMW_BALLOON_CMD_START)\
+   result = __dummy1; \
+   result &= -1UL;\
+   __status & -1UL;   \
 })
 
 #ifdef CONFIG_DEBUG_FS
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/6] x86: Add VMWare Host Communication Macros

[Sinclair Yeh]

These macros will be used by multiple VMWare modules for handling
host communication.

v2:
* Keeping only the minimal common platform defines
* added vmware_platform() check function

v3:
* Added new field to handle different hypervisor magic values

Signed-off-by: Sinclair Yeh <s...@vmware.com>
Reviewed-by: Thomas Hellstrom <thellst...@vmware.com>
Reviewed-by: Alok N Kataria <akata...@vmware.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: Alok Kataria <akata...@vmware.com>
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: Xavier Deguillard <xdeguill...@vmware.com>
---
 arch/x86/include/asm/vmware.h | 110 ++
 1 file changed, 110 insertions(+)
 create mode 100644 arch/x86/include/asm/vmware.h

diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
new file mode 100644
index 000..32bf99b
--- /dev/null
+++ b/arch/x86/include/asm/vmware.h
@@ -0,0 +1,110 @@
+/*
+ * Copyright (C) 2015, VMware, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT.  See the GNU General Public License for more
+ * details.
+ *
+ * Based on code from vmware.c and vmmouse.c.
+ * Author:
+ *   Sinclair Yeh <s...@vmware.com>
+ */
+#ifndef _ASM_X86_VMWARE_H
+#define _ASM_X86_VMWARE_H
+
+
+/**
+ * Hypervisor-specific bi-directional communication channel.  Should never
+ * execute on bare metal hardware.  The caller must make sure to check for
+ * supported hypervisor before using these macros.
+ *
+ * Several of the parameters are both input and output and must be initialized.
+ *
+ * @in1: [IN] Message Len or Message Cmd (HB)
+ * @in2: [IN] Message Len (HB) or Message Cmd
+ * @port_num: [IN] port number + [channel id]
+ * @magic: [IN] hypervisor magic value
+ * @eax: [OUT] value of EAX register
+ * @ebx: [OUT] e.g. status from an HB message status command
+ * @ecx: [OUT] e.g. status from a non-HB message status command
+ * @edx: [OUT] e.g. channel id
+ * @si: [INOUT] set to 0 if not used
+ * @di: [INOUT] set to 0 if not used
+ * @bp: [INOUT] set to 0 if not used
+ */
+#define VMW_PORT(in1, in2, port_num, magic, eax, ebx, ecx, edx, si, di) \
+({  \
+   __asm__ __volatile__ ("inl %%dx" :  \
+   "=a"(eax),  \
+   "=b"(ebx),  \
+   "=c"(ecx),  \
+   "=d"(edx),  \
+   "=S"(si),   \
+   "=D"(di) :  \
+   "a"(magic), \
+   "b"(in1),   \
+   "c"(in2),   \
+   "d"(port_num),  \
+   "S"(si),\
+   "D"(di) :   \
+   "memory");  \
+})
+
+
+#define VMW_PORT_HB_OUT(in1, in2, port_num, magic,  \
+   eax, ebx, ecx, edx, si, di, bp) \
+({  \
+   __asm__ __volatile__ ("movq %13, %%rbp;"\
+   "cld; rep outsb; "  \
+   "movq %%rbp, %6" :  \
+   "=a"(eax),  \
+   "=b"(ebx),  \
+   "=c"(ecx),  \
+   "=d"(edx),  \
+   "=S"(si),   \
+   "=D"(di),   \
+   "=r"(bp) :  \
+   "a"(magic), \
+   "b"(in1),

Re: [PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Sinclair Yeh]

Hi,

On Tue, Dec 01, 2015 at 02:24:14PM -0800, Dmitry Torokhov wrote:
> On Tue, Dec 01, 2015 at 02:18:49PM -0800, Sinclair Yeh wrote:
> > v2:
> > Instead of replacing existing VMMOUSE defines, only modify enough
> > to use the new VMW_PORT define.
> > 
> > v3:
> > Use updated VMWARE_PORT() which requires hypervisor magic as an added
> > parameter
> > 
> > Signed-off-by: Sinclair Yeh <s...@vmware.com>
> > Reviewed-by: Thomas Hellstrom <thellst...@vmware.com>
> > Reviewed-by: Alok N Kataria <akata...@vmware.com>
> > Cc: pv-driv...@vmware.com
> > Cc: linux-graphics-maintai...@vmware.com
> > Cc: Dmitry Torokhov <dmitry.torok...@gmail.com>
> > Cc: Arnd Bergmann <a...@arndb.de>
> > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> > Cc: linux-kernel@vger.kernel.org
> > Cc: virtualizat...@lists.linux-foundation.org
> > Cc: linux-in...@vger.kernel.org
> > ---
> >  drivers/input/mouse/vmmouse.c | 22 +++---
> >  1 file changed, 7 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
> > index e272f06..d34e3e4 100644
> > --- a/drivers/input/mouse/vmmouse.c
> > +++ b/drivers/input/mouse/vmmouse.c
> > @@ -19,6 +19,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include "psmouse.h"
> >  #include "vmmouse.h"
> > @@ -84,21 +85,12 @@ struct vmmouse_data {
> >   * implementing the vmmouse protocol. Should never execute on
> >   * bare metal hardware.
> >   */
> > -#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
> > -({ \
> > -   unsigned long __dummy1, __dummy2;   \
> > -   __asm__ __volatile__ ("inl %%dx" :  \
> > -   "=a"(out1), \
> > -   "=b"(out2), \
> > -   "=c"(out3), \
> > -   "=d"(out4), \
> > -   "=S"(__dummy1), \
> > -   "=D"(__dummy2) :\
> > -   "a"(VMMOUSE_PROTO_MAGIC),   \
> > -   "b"(in1),   \
> > -   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
> > -   "d"(VMMOUSE_PROTO_PORT) :   \
> > -   "memory");  \
> > +#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4) \
> > +({\
> > +   unsigned long __dummy1 = 0, __dummy2 = 0;  \
> 
> Why do we need to initialize dummies?

Because for some commands those parameters to VMW_PORT() can be both
input and outout.  So it's safer to initialize them to 0.  Since
they can potentially be an output, we can't make them a constant.

> 
> > +   VMW_PORT(in1, VMMOUSE_PROTO_CMD_##cmd, VMMOUSE_PROTO_PORT, \
> > +VMMOUSE_PROTO_MAGIC,  \
> > +out1, out2, out3, out4, __dummy1, __dummy2);  \
> >  })
> >  
> 
> Thanks.
> 
> -- 
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/