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/i915/display: Error codes for async flip failures Date: Wed, 01 Apr 2026 07:55:28 +1000 Message-ID: In-Reply-To: <20260331-atomic-v11-6-6a1df7ec5af8@intel.com> References: <20260331-atomic-v11-0-6a1df7ec5af8@intel.com> <20260331-atomic-v11-6-6a1df7ec5af8@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 **`DRM_MODE_ATOMIC_INVALID_API_USAGE` for unsupported pixel format/modifier:** ```c drm_mode_atomic_add_error_msg(&state->base.error_code, DRM_MODE_ATOMIC_INVALID_API_USAGE, "[PLANE:%d:%s] pixel format %p4cc / 0x%llx modifier does not support async flip", ``` Using `INVALID_API_USAGE` for "this hardware doesn't support this format/modifier combo with async flip" seems wrong. This isn't invalid API usage; the API is being used correctly but the hardware can't do it. `DRM_MODE_ATOMIC_SPEC_VIOLOATION` (typo aside) seems more appropriate, or a new code. **`%p4cc` format specifier in `kvasprintf`:** The `%p4cc` format is a kernel-specific `printk` extension for fourcc codes. `kvasprintf` should support it since it uses the kernel's `vsnprintf`, but this is worth verifying. It will produce something like `XR24 little-endian` in the error string -- is that useful for userspace? **Only partial coverage:** Only a few error paths in `intel_async_flip_check_uapi` and `intel_async_flip_check_hw` are converted. Many other error returns in these functions still use `drm_dbg_kms` without setting an error code. This means userspace will get `DRM_MODE_ATOMIC_UNSPECIFIED_ERROR` (0) for those cases, which defeats the purpose. --- --- Generated by Claude Code Patch Reviewer