Claude review: drm/panthor: Implement evicted status for GEM objects

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

Patch Review

**Overall:** Well-designed implementation using `atomic_t` for the reclaimed counter with INT_MAX saturation.

**`atomic_add_unless` for saturation:** Correct approach.

```c
atomic_add_unless(&bo->reclaimed_count, 1, INT_MAX);
```

This atomically increments unless the value is already INT_MAX, providing clean saturation semantics. Placed correctly before the actual eviction cleanup.

**Status callback logic:**

```c
if (drm_gem_is_imported(&bo->base) || bo->backing.pages)
    res |= DRM_GEM_OBJECT_RESIDENT;
else if (atomic_read(&bo->reclaimed_count))
    res |= DRM_GEM_OBJECT_EVICTED;
```

The `else if` correctly makes RESIDENT and EVICTED mutually exclusive. An object that is swapped back in (`backing.pages` non-NULL again) will show as RESIDENT, not EVICTED — which is the correct current-state semantics. The `reclaimed_count` provides the historical record. The distinction between "never had pages" (reclaimed_count == 0, neither RESIDENT nor EVICTED) and "had pages but were evicted" (reclaimed_count > 0, EVICTED) is exactly the gap this series fills.

**Race between `backing.pages` and `reclaimed_count`:** These are read without holding locks in the status callback (called under `file->table_lock` spinlock, not dma_resv). A concurrent shrinker could evict the object between reading `backing.pages` and `reclaimed_count`. This is acceptable — fdinfo is inherently racy and will be correct on the next poll.

**Zero-initialization:** `reclaimed_count` is implicitly zero-initialized via `kzalloc_obj(*bo)` in `panthor_gem_alloc_object()`, so newly allocated objects correctly start with count 0.

**debugfs state flag:**

```c
if (drm_gem_is_imported(&bo->base))
    gem_state_flags |= PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED;
else if (!resident_size && reclaimed_count)
    gem_state_flags |= PANTHOR_DEBUGFS_GEM_STATE_FLAG_EVICTED;
```

The `else if` is correct — imported BOs are always considered resident by panthor and are not managed by the shrinker, so they can never be in the evicted state.

**Format string update:** The new `%-11d` for `reclaimed_count` is correct (INT_MAX = 2147483647, 10 digits + 1 space = 11 chars). The column header "evictions" (9 chars) fits within the 11-char field.

**No issues with:** enum definitions, kerneldoc for `reclaimed_count`, debugfs flag name table update.

---

---
Generated by Claude Code Patch Reviewer