Claude review: bus: mhi: Capture DDR training data using command mode

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

Patch Review

This is the most complex patch and has the most serious issues.

**Issues:**

- **Bug: Unsigned comparison always false** at `sahara.c:706`:
  ```c
  le32_to_cpu(context->rx->command_execute_resp.response_length) < 0
  ```
  `le32_to_cpu()` returns `u32`. This comparison is always false and provides no validation.

- **Bug: Sleeping in atomic context.** `sahara_mhi_dl_xfer_cb()` (line 1367) is an MHI transfer callback that can run in tasklet/softirq context. It calls:
  - `sahara_ctrl_trng_get()` → `devres_alloc(..., GFP_KERNEL)` — may sleep
  - `mutex_lock(&ct->lock)` — may sleep
  
  Both are illegal in atomic context.

- **Bug: Unbounded `kzalloc` from device-controlled value** at `sahara.c:735`:
  ```c
  ct->data = kzalloc(resp_len, GFP_KERNEL);
  ```
  `resp_len` comes directly from the device with no upper bound. A malicious/buggy device could cause an enormous allocation. Add a sanity cap.

- **Bug: `ct->data` checked outside the lock** at `sahara.c:741`:
  ```c
  mutex_unlock(&ct->lock);
  if (!ct->data) { ...
  ```
  After releasing the lock, `ct->data` could be freed by another thread. Move the NULL check inside the critical section.

- **Data races**: `context->is_cmd_mode`, `receiving_trng_data`, `trng_rcvd`, `trng_size`, `trng_nbuf` are accessed from both the DL callback (potentially tasklet context) and the work queue without any locking or memory barriers.

- **TX buffer reuse**: At `sahara.c:716-719`, `sahara_command_execute_data()` and `sahara_command_execute()` both write to `context->tx[0]` and queue it. The first may not have been consumed by MHI before the second overwrites it.

- **Missing `cancel_work_sync(&context->read_data_work)`** in the remove path (line 1347-1357). Only `fw_work`, `dump_work`, and `cmd_work` are cancelled.

---
Generated by Claude Code Patch Reviewer