Claude review: accel/ethosu: fix integer overflow in dma_length()

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

Patch Review

This is v1 and is **superseded by v3**. It only addresses multiplication overflow:

```c
-		len *= dma_st->size0;
+		if (check_mul_overflow(len, (u64)dma_st->size0, &len))
+			return U64_MAX;
```

**Issues in v1:**

1. **Missing negative stride underflow check.** Before the multiplication, `len += dma->stride[0]` adds a signed `s64` to an unsigned `u64`. If `stride[0]` is a large negative value (sign-extended from 40-bit input), this wraps `len` to a huge value. With `size0 == 1`, `check_mul_overflow` does not trigger, and the result is a garbage length.

2. **Missing caller validation.** The commit message claims "the callers of dma_length() already treat U64_MAX as an error sentinel," but looking at the caller at the original line 397–400 (now line 407), `srclen`/`dstlen` were only used in a `dev_dbg()` format string — the return value was never checked for `U64_MAX`. This means even when `dma_length()` returns `U64_MAX`, the `info->region_size[]` entry would remain at 0 (never updated because the function returned early), and the region would be skipped entirely by `ethosu_job.c` at line 420/670, allowing stale physical addresses through. This claim in the commit message is **incorrect** for the `NPU_OP_DMA_START` case.

3. **Missing `len + dma->offset` overflow check** at the `region_size` update.

---
Generated by Claude Code Patch Reviewer