Claude review: accel: ethosu: Handle possible underflow in IFM size calculations

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

Patch Review

The fix changes `ifm_height` and `ifm_width` from `u32` to `s32` and adds an early check for negative values:

> -		u32 ifm_height = st->ofm.height[2] * stride_y +
> +		s32 ifm_height = st->ofm.height[2] * stride_y +
>  			st->ifm.height[2] - (st->ifm.pad_top + st->ifm.pad_bottom);
> -		u32 ifm_width  = st->ofm.width * stride_x +
> +		s32 ifm_width = st->ofm.width * stride_x +
>  			st->ifm.width - (st->ifm.pad_left + st->ifm.pad_right);
>
> +		if (ifm_height < 0 || ifm_width < 0)
> +			return -EINVAL;

The arithmetic itself is worth examining. `st->ofm.height[2]` is `u16`, `stride_y` is `u32` (max value 4), `st->ifm.height[2]` is `u16`, and `pad_top`/`pad_bottom` are `u8`. The maximum positive value is roughly `0xFFFF * 4 + 0xFFFF = 327675`, which fits comfortably in `s32`. The minimum value when padding dominates is `0 + 0 - (255 + 255) = -510`, which is representable in `s32`. So the type change is safe.

The values then get passed to `feat_matrix_length(info, &st->ifm, ifm_width, ifm_height, st->ifm.depth)` which takes `u32` parameters. Since the negative check happens before the call, only non-negative `s32` values reach the function, and the implicit conversion to `u32` is well-defined. No issues found. The commit message accurately describes the problem with padding values exceeding IFM dimensions and the mesa driver bug that triggered it.

---
Generated by Claude Code Patch Reviewer