Claude review: drm/panel: boe-tv101wum-nl6: restore MODE_LPM after sending disable cmds

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

Patch Review

**The bug:** In `boe_panel_disable()` (line 1322 of the current tree), the driver clears `MIPI_DSI_MODE_LPM`:

```c
boe->dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
```

This is intentional — the display-off and sleep-enter DCS commands should be sent in HS mode. However, the flag is never restored, so on the next prepare/init cycle (which doesn't independently set LPM), commands are sent in HS mode when LP mode is expected.

**The fix is correct.** The patch adds:

```c
boe->dsi->mode_flags |= MIPI_DSI_MODE_LPM;
```

This matches the established pattern in other panel drivers. The `Fixes:` tag and `Cc: stable` are appropriate since this is a clear regression-fix for the original driver commit.

**Minor placement concern:** The restore is inserted *between* `mipi_dsi_dcs_enter_sleep_mode_multi()` and the `mipi_dsi_msleep(&ctx, 150)` delay. Most other drivers that follow this pattern (e.g., `panel-boe-bf060y8m-aj0` at line 102) restore LPM *after* the final delay in the off sequence. In this driver the `mipi_dsi_msleep` is a multi-context sleep, which checks `ctx.accum_err` but doesn't issue DSI commands, so the placement is functionally harmless. Still, placing the restore **after** the `mipi_dsi_msleep()` and before the `return` would be slightly cleaner — it keeps all HS-mode operations (including the sleep delay that's part of the disable sequence) grouped together, and restores LPM only once the disable sequence is truly complete. This is a style nit, not a correctness issue.

**Commit message:** Clear, explains the problem, the fix, and the real-world impact (error messages on mt8183-kukui-kodama-sku32). Well written.

**Overall: Looks good.** Reviewed-by worthy, optionally with the minor suggestion to move the restore after the msleep.

---
Generated by Claude Code Patch Reviewer