Claude review: drm/mipi-dsi: add RGB101010 pixel format

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

Patch Review

**Enum ordering concern:** The new `MIPI_DSI_FMT_RGB101010` is inserted at the **top** of the enum:

```c
 enum mipi_dsi_pixel_format {
+	MIPI_DSI_FMT_RGB101010,
 	MIPI_DSI_FMT_RGB888,
```

This changes the implicit numeric values of all existing members (`MIPI_DSI_FMT_RGB888` goes from 0 to 1, etc.). While current in-tree users appear to use symbolic names in switch statements rather than relying on numeric values, this is still bad practice. There are 137+ files using these enum values across the DRM subsystem. Any out-of-tree driver or userspace tool that has hardcoded the numeric values would break.

**Recommendation:** Append the new value at the end, after `MIPI_DSI_FMT_RGB565`:

```c
enum mipi_dsi_pixel_format {
	MIPI_DSI_FMT_RGB888,
	MIPI_DSI_FMT_RGB666,
	MIPI_DSI_FMT_RGB666_PACKED,
	MIPI_DSI_FMT_RGB565,
	MIPI_DSI_FMT_RGB101010,
};
```

**Missing handling in `drm_mipi_dsi_get_input_bus_fmt()`:** The function at `drm_mipi_dsi.c:888` switches on all four existing formats and falls through to a `default` case. Adding `MIPI_DSI_FMT_RGB101010` without a corresponding case there will cause compiler warnings (`-Wswitch`) in some configurations, and the function will return 0 for this format. A `MEDIA_BUS_FMT_RGB101010_1X30` case should be added (or the function should explicitly handle it, even if just falling to default with a comment).

The `mipi_dsi_pixel_format_to_bpp()` addition returning 30 is correct.

Already has Reviewed-by from Dmitry Baryshkov, which is good.

---

---
Generated by Claude Code Patch Reviewer