From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/xe/uapi: Define drm_xe_vm_get_property Date: Sun, 22 Mar 2026 03:27:30 +1000 Message-ID: In-Reply-To: <20260320183547.61017-8-jonathan.cavitt@intel.com> References: <20260320183547.61017-6-jonathan.cavitt@intel.com> <20260320183547.61017-8-jonathan.cavitt@intel.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review **uAPI naming convention issue**: The `struct xe_vm_fault` and defines like `FAULT_ACCESS_TYPE_READ`, `FAULT_TYPE_NOT_PRESENT`, `FAULT_LEVEL_PTE` don't follow the `drm_xe_` / `DRM_XE_` naming convention used everywhere else in `xe_drm.h`. These generic names risk collisions with other kernel/userspace headers. They should be: - `struct drm_xe_vm_fault` - `DRM_XE_VM_FAULT_ACCESS_TYPE_READ` (etc.) - `DRM_XE_VM_FAULT_TYPE_NOT_PRESENT` (etc.) - `DRM_XE_VM_FAULT_LEVEL_PTE` (etc.) **Missing `pad` MBZ validation in struct docs**: The `pad` field in `struct xe_vm_fault` is documented as MBZ. The ioctl handler (patch 4) never validates that `pad` is zero on output, nor does it validate `extensions` in `struct drm_xe_vm_get_property`. These should be checked to preserve forward compatibility. **Struct size**: `struct xe_vm_fault` is `8 + 4 + 1 + 1 + 1 + 1 + 32 = 48` bytes, which is nicely aligned. The `reserved[4]` provides 32 bytes for future expansion which seems generous. The two-phase size query / data fetch pattern is a reasonable approach for the ioctl design. --- --- Generated by Claude Code Patch Reviewer