Claude review: soc: cadence: Create helper functions for Cadence MHDP

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

Patch Review

**Placement under `drivers/soc/cadence/`**: This is somewhat unconventional. Mailbox helpers for a DRM bridge IP typically live under `drivers/gpu/drm/bridge/` or at least `include/drm/`. Putting it under `drivers/soc/` makes sense only if the PHY driver also uses it (which it does), but it creates an unusual dependency path. Prior discussion may have settled this; worth confirming the subsystem maintainer is comfortable.

**Global mutex concern:**
```c
static DEFINE_MUTEX(mhdp_mailbox_mutex);
```
A process-wide static mutex means all MHDP instances (across different SoC blocks or even different SoCs sharing the kernel) are serialized. A per-instance mutex stored in `struct cdns_mhdp_base` would be more correct. The original mhdp8546 code used per-instance `mhdp->mbox_mutex`.

**Typo in error message:**
```c
dev_err(base->dev, "ModuleID=%d, Resp_CMD=%d recv data1 failed: %d\n",
```
In `cdns_mhdp_mailbox_send_recv_multi()`, the second `mhdp_mailbox_recv_data` failure prints "recv data1" instead of "recv data2".

**Typo in commit message:**
> "These helper fucntions will be reused..."

Should be "functions".

**Kerneldoc `@param` format:** The kerneldoc uses `@param base:` which is not standard kernel kerneldoc format; it should be `@base:` (without `@param`). This applies to all the exported functions in this file.

**`HDCP_TRAN_IS_REC_ID_VALID` special-casing in `cdns_mhdp_secure_mailbox_send_recv_multi`:**
```c
if (module_id == MB_MODULE_ID_HDCP_TX &&
    opcode == HDCP_TRAN_IS_REC_ID_VALID)
    ret = mhdp_mailbox_recv_data(base->sapb_regs, resp2, 5 * resp1[0]);
```
This HDCP-specific logic in a generic helper is a code smell. The caller should handle the dynamic size by passing the correct `resp2_size`. Having the helper know about HDCP protocol details leaks abstraction.

---
Generated by Claude Code Patch Reviewer