Claude review: drm/bridge: imx93-mipi-dsi: Fix mode validation

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

Patch Review

**Problem analysis:** Correct. The old code at line 496-497:
```c
struct drm_bridge *last_bridge __free(drm_bridge_put) =
    drm_bridge_chain_get_last_bridge(dmd_bridge->encoder);
```
only checked the terminal bridge. When a connector bridge (e.g., `drm_connector_bridge`) sits at the end of the chain without `DRM_BRIDGE_OP_DETECT` or `DRM_BRIDGE_OP_EDID`, the tolerance path was never entered, causing valid modes to be rejected.

**Fix analysis:** The replacement iterates from `dmd_bridge` forward:
```c
drm_for_each_bridge_in_chain_from(dmd_bridge, bridge) {
    if ((bridge->ops & DRM_BRIDGE_OP_DETECT) &&
        (bridge->ops & DRM_BRIDGE_OP_EDID)) {
        ...
        break;
    }
}
```

This is correct. The `drm_for_each_bridge_in_chain_from()` macro (defined in `drm_bridge.h:1532`) declares `bridge` with `__free(__drm_for_each_bridge_in_chain_cleanup)`, so both the `return MODE_NOCLOCK` early-exit and the normal `break` path properly unlock the chain mutex and drop the bridge reference. This replaces the explicit `__free(drm_bridge_put)` cleanup on the old `last_bridge` variable.

**Minor observation:** The iteration starts from `dmd_bridge` inclusive, so the DW MIPI DSI bridge itself is checked. It won't have the ops bits set, so this is harmless but slightly broader than "bridges after this bridge" as stated in the commit message. Not a problem.

**Nit (not blocking):** The `break` after the tolerance check exits the loop on the first matching bridge. If there were somehow multiple bridges with `DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID` in the chain, only the first one would be considered. This is the right behavior for the described topology.

No issues found. The patch is correct and ready to apply.

---
Generated by Claude Code Patch Reviewer