Claude review: drm: bridge: cadence: Update mhdp8546 mailbox access functions

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

Patch Review

Mechanical conversion of the existing mhdp8546 driver to use the new shared helpers. Well done — removes ~550 lines of duplicated code.

**Issues:**

1. **Data duplication in `cdns_mhdp_device`**: The patch adds `struct cdns_mhdp_base base` which contains `regs`, `sapb_regs`, and `dev` pointers, but the existing struct already has these same fields. In probe:
```c
mhdp->base.dev = mhdp->dev;
mhdp->base.regs = mhdp->regs;
mhdp->base.sapb_regs = mhdp->sapb_regs;
```
This creates two copies of the same pointers. Consider embedding `base` at the start of the struct and removing the duplicate fields, or at least making the existing fields point into `base`.

2. **`set_firmware_active` response handling changed**: The old code sent a raw 5-byte message and read back a response. The new code uses `cdns_mhdp_mailbox_send_recv()` with `sizeof(status)` (1 byte) for both message and response sizes. The old message was 5 bytes (including header). Make sure the firmware protocol is actually `send(1 byte) → recv(1 byte)` and not `send(5 bytes including header)`.

3. **`disable_irq`/cancel work ordering in remove()**: The patch adds:
```c
disable_irq(mhdp->irq);
cancel_work_sync(&mhdp->modeset_retry_work);
flush_work(&mhdp->hpd_work);
```
before `wait_event_timeout`. The original code did `cancel_work_sync` + `flush_work` after `pm_runtime_put_sync`. Moving `disable_irq` to the top of remove is correct for preventing new work from being scheduled, but the `drm_bridge_remove()` call above it may trigger disconnect callbacks that reference the device — ensure there's no ordering issue with the bridge still being live when the IRQ is disabled.

4. **`mutex_destroy` without corresponding `mutex_init` movement**: `mutex_init(&mhdp->base.mailbox_mutex)` is in probe, and `mutex_destroy(&mhdp->base.mailbox_mutex)` is in remove. But the old `mutex_init(&mhdp->mbox_mutex)` is removed without adding the destroy. This is correct since the new mutex is the replacement, but the asymmetric placement (init in probe, destroy at end of remove after pm_runtime_disable) is fine.

---
Generated by Claude Code Patch Reviewer