Claude review: drm: Define user readable error codes for atomic ioctl

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Typos in UAPI enum names (permanent ABI breakage):**
```c
DRM_MODE_ATTOMIC_CONNECTOR_BW,
DRM_MODE_ATTOMIC_PIPE_BW,
DRM_MODE_ATOMIC_SPEC_VIOLOATION,
```
These should be `DRM_MODE_ATOMIC_CONNECTOR_BW`, `DRM_MODE_ATOMIC_PIPE_BW`, and `DRM_MODE_ATOMIC_SPEC_VIOLATION`. Once merged, these misspellings are permanent UAPI.

**Typos in kernel-doc:**
```c
 * @DRM_MODE_ATOMIC_INVALID_API_USAGE: invallid API usage(DRM_ATOMIC not
 *				       enabled, invalid falg, page_flip event
```
"invallid" should be "invalid", "falg" should be "flag".

**Kernel-doc for `drm_mode_atomic_err_code`:**
```c
 * @failure_code: error codes defined in enum drm_moide_atomic_failure_code
```
"drm_moide_atomic_failure_code" should be "drm_mode_atomic_failure_codes".

**Design concern with `failure_objs_ptr`:** This field is a `__u64` pointer to DRM objects, but there's no documentation on what the pointed-to data looks like. Is it an array of `__u32` object IDs? What allocates/frees this memory? None of the patches in this series actually populate it, so it's dead UAPI surface area.

**`__u64` for `failure_code`:** The enum only has 9 values. Using `__u32` would be more natural and leave the `__u64 reserved` for actual expansion. The current layout wastes space.

**`failure_string` as a fixed 128-byte char array inside a struct that gets `copy_to_user`'d:** This is 128 bytes copied on every failed atomic commit. Consider whether this is the right tradeoff vs. a userspace-provided buffer.

---

---
Generated by Claude Code Patch Reviewer