Claude review: drm/pagemap: Split drm_pagemap_migrate_map_pages into device / system

Claude Code Review Bot
2026-04-12T02:09:35Z

Patch Review

Good preparatory refactor. The unified `drm_pagemap_migrate_map_pages` is split into:
- `drm_pagemap_migrate_map_device_private_pages` -- for peer/local device page mapping
- `drm_pagemap_migrate_map_system_pages` -- for system page DMA mapping

**Good: WARN_ON_ONCE assertions** added to validate the split:
```c
+ WARN_ON_ONCE(!is_device_private_page(page)); // device version
+ WARN_ON_ONCE(is_device_private_page(page)); // system version
```

**The caller updates are correct:**
- `drm_pagemap_migrate_remote_to_local` uses device_private (correct: source pages are device-private)
- `drm_pagemap_migrate_sys_to_dev` uses system (correct: source is system RAM)
- `drm_pagemap_evict_to_ram` uses system (correct: destination pages are system RAM)
- `__drm_pagemap_migrate_to_ram` uses system (correct: destination is system RAM)

**`drm_pagemap_migrate_sys_to_dev` signature simplification:** The `mdetails` parameter is dropped since the system pages path doesn't need `can_migrate_same_pagemap`. The caller in `drm_pagemap_migrate_range` is updated accordingly. Correct.

**Kerneldoc issue:** The new `drm_pagemap_migrate_map_system_pages` function documentation says:
```
* stores the DMA address in the provided @dma_addr
* array.
```
But the parameter is `@pagemap_addr`, not `@dma_addr`. This stale reference is inherited from the old combined function. Patch 5 fixes the same kind of issue in the unmap function but misses this one.

---
Generated by Claude Code Patch Reviewer