All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: Jonathan Cavitt <jonathan.cavitt@intel.com>
Cc: <dri-devel@lists.freedesktop.org>, <alex.zuo@intel.com>,
	<intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH] drm/xe: Rename xe_vm_fault to drm_xe_vm_fault
Date: Thu, 3 Sep 2026 17:16:55 -0700	[thread overview]
Message-ID: <apoN91t7qC1orEC+@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <20260903231632.399765-1-jonathan.cavitt@intel.com>

On Fri, Sep 04, 2026 at 07:16:32AM +0800, Jonathan Cavitt wrote:
> Rename xe_vm_fault to drm_xe_vm_fault to better align with uAPI struct
> naming conventions.
> 
> Suggested-by: Matthew Brost <matthew.brost@intel.com>

Sashiko raised a concern that this could break compilation. I suppose
that's probably correct if, for example, a project is built against
headers installed on a machine. However, I think most projects include
the header directly in the project. Mesa, for example, does this in
`./include/drm-uapi/xe_drm.h`.

So I'd say this is a non-issue. When a project pulls in the new header,
it can fix the compilation changes in tandem.

That said, let's make sure we get an ack from Mesa (which I believe is
the only UAPI user) before merging this change.

With that:
Reviewed-by: Matthew Brost <matthew.brost@intel.com>

> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_vm.c | 14 +++++++-------
>  include/uapi/drm/xe_drm.h  |  4 ++--
>  2 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
> index 753a5fc55baa0..22ce6f8dfb783 100644
> --- a/drivers/gpu/drm/xe/xe_vm.c
> +++ b/drivers/gpu/drm/xe/xe_vm.c
> @@ -4286,15 +4286,15 @@ static u8 xe_to_user_srcid(u8 srcid)
>  static int fill_faults(struct xe_vm *vm,
>  		       struct drm_xe_vm_get_property *args)
>  {
> -	struct xe_vm_fault __user *usr_ptr = u64_to_user_ptr(args->data);
> -	struct xe_vm_fault *fault_list, fault_entry = { 0 };
> +	struct drm_xe_vm_fault __user *usr_ptr = u64_to_user_ptr(args->data);
> +	struct drm_xe_vm_fault *fault_list, fault_entry = { 0 };
>  	struct xe_vm_fault_entry *entry;
>  	int ret = 0, i = 0, count, entry_size;
>  
> -	entry_size = sizeof(struct xe_vm_fault);
> +	entry_size = sizeof(struct drm_xe_vm_fault);
>  	count = args->size / entry_size;
>  
> -	fault_list = kcalloc(count, sizeof(struct xe_vm_fault), GFP_KERNEL);
> +	fault_list = kcalloc(count, sizeof(struct drm_xe_vm_fault), GFP_KERNEL);
>  	if (!fault_list)
>  		return -ENOMEM;
>  
> @@ -4332,7 +4332,7 @@ static int xe_vm_get_property_helper(struct xe_vm *vm,
>  	switch (args->property) {
>  	case DRM_XE_VM_GET_PROPERTY_FAULTS:
>  		spin_lock(&vm->faults.lock);
> -		size = size_mul(sizeof(struct xe_vm_fault), vm->faults.len);
> +		size = size_mul(sizeof(struct drm_xe_vm_fault), vm->faults.len);
>  		spin_unlock(&vm->faults.lock);
>  
>  		if (!args->size) {
> @@ -4347,9 +4347,9 @@ static int xe_vm_get_property_helper(struct xe_vm *vm,
>  		 * the number of faults in the VM fault array.
>  		 *
>  		 * We should also at least assert that the args->size value
> -		 * is a multiple of the xe_vm_fault struct size.
> +		 * is a multiple of the drm_xe_vm_fault struct size.
>  		 */
> -		if (args->size > size || args->size % sizeof(struct xe_vm_fault))
> +		if (args->size > size || args->size % sizeof(struct drm_xe_vm_fault))
>  			return -EINVAL;
>  
>  		return fill_faults(vm, args);
> diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> index 8c852abcacf0d..89c0dbe227dd7 100644
> --- a/include/uapi/drm/xe_drm.h
> +++ b/include/uapi/drm/xe_drm.h
> @@ -1271,8 +1271,8 @@ struct drm_xe_vm_bind {
>  	__u64 reserved[2];
>  };
>  
> -/** struct xe_vm_fault - Describes faults for %DRM_XE_VM_GET_PROPERTY_FAULTS */
> -struct xe_vm_fault {
> +/** struct drm_xe_vm_fault - Describes faults for %DRM_XE_VM_GET_PROPERTY_FAULTS */
> +struct drm_xe_vm_fault {
>  	/** @address: Canonical address of the fault */
>  	__u64 address;
>  	/** @address_precision: Precision of faulted address */
> -- 
> 2.53.0
> 

  parent reply	other threads:[~2026-09-04  0:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03 23:16 [PATCH] drm/xe: Rename xe_vm_fault to drm_xe_vm_fault Jonathan Cavitt
2026-09-03 23:22 ` sashiko-bot
2026-09-03 23:24 ` ✓ CI.KUnit: success for " Patchwork
2026-09-04  0:09 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-04  0:16 ` Matthew Brost [this message]
2026-09-04 13:26 ` ✗ Xe.CI.FULL: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=apoN91t7qC1orEC+@gsse-cloud1.jf.intel.com \
    --to=matthew.brost@intel.com \
    --cc=alex.zuo@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jonathan.cavitt@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.