Claude review: udmabuf: fix DMA direction mismatch in release_udmabuf()

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

Patch Review

**Commit message:** Well-written. Clearly describes the problem, how to reproduce it, and the fix. The `Fixes:` tag and `Cc: stable` are appropriate.

**Code review:**

The new field addition is clean:

```c
struct sg_table *sg;
enum dma_data_direction sg_dir;
```

Since `ubuf` is allocated with `kzalloc()` (line 384), `sg_dir` is implicitly initialized to `0` which is `DMA_BIDIRECTIONAL`. This is fine because `sg_dir` is only read when `ubuf->sg != NULL`, and `sg_dir` is always set before `ubuf->sg` becomes non-NULL.

The fix in `release_udmabuf()` is correct:

```c
if (ubuf->sg)
    put_sg_table(dev, ubuf->sg, ubuf->sg_dir);
```

The direction is properly stored only on successful mapping:

```c
} else {
    ubuf->sg_dir = direction;
}
```

**One observation (pre-existing, not introduced by this patch):** In `begin_cpu_udmabuf()`, when `ubuf->sg` already exists (the `else` branch at line 260-261), `dma_sync_sgtable_for_cpu()` is called with the new `direction` parameter, which could differ from the direction the sg_table was originally mapped with. Strictly speaking, the DMA API requires sync operations to use the same direction as the original mapping. For example, if the first call maps with `DMA_TO_DEVICE` and a second call tries to sync with `DMA_FROM_DEVICE`, that would be an API misuse. This is a pre-existing issue, not caused by this patch, but the author may want to consider it as a follow-up (e.g., either enforce that the direction matches, or remap with the new direction).

**No issues found with this patch itself.**

Reviewed-by assessment: The patch is correct and ready to be applied.

---
Generated by Claude Code Patch Reviewer