Claude review: drm/pagemap: Add helper to access zone_device_data

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

Patch Review

**Good:** Centralizes `zone_device_data` access through `drm_pagemap_page_zone_device_data()`, which correctly goes through the folio API (`page_folio()` → `folio_zone_device_data()`). This prepares for THP where only the head page's `zone_device_data` is meaningful.

**Concern — `folio_zone_device_data` only checks `folio_is_device_private`:**

Looking at the kernel's `folio_zone_device_data()`:
```c
static inline void *folio_zone_device_data(const struct folio *folio)
{
    VM_WARN_ON_FOLIO(!folio_is_device_private(folio), folio);
    return folio->page.zone_device_data;
}
```

This will trigger a `VM_WARN` if called on a device-coherent folio. The existing code in `drm_pagemap.c` accesses `zone_device_data` on both device-private and device-coherent pages (e.g., `drm_pagemap_migrate_unmap_pages` checks `is_zone_device_page` which covers both). In `drm_gpusvm.c` the call site at line 1493 also checks `is_device_coherent_page`. So the new helper will produce `VM_WARN` on coherent pages in debug builds. This seems like a pre-existing issue with the `folio_zone_device_data` API rather than this patch specifically, but it's worth noting — the callers in `drm_pagemap_migrate_unmap_pages` at line 325-326 use `is_zone_device_page` which includes coherent pages.

**Good:** The `#else` stub returning NULL for `!CONFIG_ZONE_DEVICE` is correctly placed (the v9 changelog notes this was a build fix).

**Minor:** In `drm_pagemap_folio_free`:
```c
struct page *page = folio_page(folio, 0);
drm_pagemap_zdd_put(drm_pagemap_page_zone_device_data(page));
```
This could simply use `folio_zone_device_data(folio)` directly without the extra `folio_page` + `page_folio` round-trip inside the helper. Not a bug, just a minor indirection.

---
Generated by Claude Code Patch Reviewer