Claude review: media: hantro: attach dma_resv release fence at buf_queue

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

Patch Review

**Fence attached to both OUTPUT and CAPTURE queues**

`hantro_buf_queue` handles both OUTPUT and CAPTURE buffers. The fence is attached unconditionally after `v4l2_m2m_buf_queue`:
```c
v4l2_m2m_buf_queue(ctx->fh.m2m_ctx, vbuf);
...
(void)vb2_buffer_attach_release_fence(vb);
```

For OUTPUT queues (compressed input to decoder), the device *reads* from the buffer -- it doesn't write. Attaching a `DMA_RESV_USAGE_WRITE` fence is semantically wrong. The fence should only be attached to CAPTURE (destination) buffers. Consider:
```c
if (V4L2_TYPE_IS_CAPTURE(vb->vb2_queue->type))
    (void)vb2_buffer_attach_release_fence(vb);
```

Alternatively, the core helper could take a `usage` parameter and the driver could pass `DMA_RESV_USAGE_READ` for OUTPUT queues, but for the stated use case (compositors consuming decoded frames), limiting to CAPTURE is simpler and correct.

**EOS path is correctly handled**

The EOS early-return at the top of the function calls `v4l2_m2m_last_buffer_done()` and returns before reaching the fence attachment, so no fence is attached to EOS marker buffers. This is correct.

**Comment is overly verbose**

The 8-line comment block repeats information from the commit message and the core helper's kdoc. A single line like `/* Attach dma_resv release fence for implicit sync consumers */` would be sufficient.

---

---
Generated by Claude Code Patch Reviewer