Claude review: drm/exynos: fix size_t format string

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

Patch Review

**Correctness of the format changes:**

The two format changes are correct:

1. `%lx` → `%zx` for `exynos_gem->base.size` (which is `size_t`): Correct. `%zx` is the proper portable format specifier for `size_t`.

2. `%lx` with `(unsigned long)` cast → `%pad` with `&` for `exynos_gem->dma_addr` (which is `dma_addr_t`): Correct. `%pad` is the kernel's recommended format for `dma_addr_t` and takes a pointer to the value.

**Minor inconsistency between the two hunks:**

In `exynos_drm_alloc_buf`, the format string is:
```c
"dma_addr(%pad), size(0x%zx)\n"
```

But in `exynos_drm_free_buf`, the format string is:
```c
"dma_addr(0x%pad), size(0x%zx)\n"
```

The `0x` prefix before `%pad` in the second hunk is incorrect — `%pad` already includes the `0x` prefix in its output (it uses `phys_addr_t` formatting which prepends `0x`). This would result in output like `dma_addr(0x0x12345678)` in the free path. The first hunk correctly omits the `0x` prefix.

Looking at the diff more closely:

```
-	DRM_DEV_DEBUG_KMS(dev->dev, "dma_addr(0x%lx), size(0x%lx)\n",
-			(unsigned long)exynos_gem->dma_addr, exynos_gem->base.size);
+	DRM_DEV_DEBUG_KMS(dev->dev, "dma_addr(0x%pad), size(0x%zx)\n",
+			  &exynos_gem->dma_addr, exynos_gem->base.size);
```

The `0x` was left in front of `%pad` in the second hunk but correctly removed in the first hunk. This should be `"dma_addr(%pad), size(0x%zx)\n"` to be consistent and avoid the double-prefix.

**Alignment fix:** The patch also adjusts continuation line alignment from tabs to spaces to match the opening parenthesis, which is a nice cleanup.

**Recommendation:** The `0x%pad` in the second hunk should be changed to just `%pad` to match the first hunk and avoid doubled `0x` output. Otherwise the patch is correct and should be applied.

---
Generated by Claude Code Patch Reviewer