Claude review: drm: renesas: rzg2l_mipi_dsi: Fix assert of CMN_RSTB signal

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

Patch Review

Moves `reset_control_assert(dsi->rstc)` from `rzg2l_mipi_dsi_dphy_exit()` to `rzg2l_mipi_dsi_stop()`, placing it **before** the `dphy_exit()` call.

```c
 static void rzg2l_mipi_dsi_stop(struct rzg2l_mipi_dsi *dsi)
 {
+	reset_control_assert(dsi->rstc);
 	dsi->info->dphy_exit(dsi);
 	pm_runtime_put(dsi->dev);
 }
```

**Question on ordering:** The commit message says "placing it before the dphy_exit() call." The original code had the assert at the *end* of `dphy_exit()` — so it was after the PHY power-down sequence. Now it's *before* the PHY power-down. Is asserting CMN_RSTB before powering down the PHY (clearing EN_LDO1200, EN_BGR) the correct hardware sequence? The commit message doesn't explain *why* the assert must come before `dphy_exit()` rather than after. The hardware manual section cited is about the reset sequence, so if the manual says assert first then power down, this is fine, but it would be good to have that clarified in the commit message.

**Fixes tags:** The two `Fixes:` tags reference commits that add OF data support and lanes checking. These seem tangential — the original placement of `reset_control_assert()` in `dphy_exit()` dates back to the initial driver commit, not to these fixes-referenced commits. The `Fixes:` tags should point to the commit that originally placed the assert in the wrong location.

**RZ/V2H note:** The commit message says "Since this reset signal is optional for RZ/V2H, the call is a no-op on that SoC." This is correct — `dsi->rstc` is obtained via `devm_reset_control_get_optional_exclusive()`, so it will be NULL when not present, and `reset_control_assert(NULL)` is a no-op.

---
Generated by Claude Code Patch Reviewer