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

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

Patch Review

The new enum member is added before `MIPI_DSI_FMT_RGB888`:

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

This shifts the numeric values of all existing members (RGB888 goes from 0 to 1, etc.). While all in-tree usage is by symbolic name, **adding new enum values at the end is conventional practice** in the kernel to minimize risk from out-of-tree consumers or any code that might serialize/deserialize these values. Consider placing it after `MIPI_DSI_FMT_RGB565` instead.

The `mipi_dsi_pixel_format_to_bpp` addition returning 30 is correct per MIPI DSI v1.3 Section 8.8.17.

Note: `drm_mipi_dsi_get_input_bus_fmt()` in `drm_mipi_dsi.c` has a `default` case returning 0 for the new format — this means any bridge driver calling that function for RGB101010 will silently get a 0 bus format. That's acceptable for now since no bridge currently supports RGB101010 on the input side, but a `MEDIA_BUS_FMT_RGB101010_1X30` mapping may eventually be needed.

Also: several drivers do `mipi_dsi_pixel_format_to_bpp(...) / 8` to get bytes-per-pixel (e.g., `sun6i_mipi_dsi.c`, `mcde_dsi.c`). For 30bpp, `30 / 8 = 3` (integer truncation), which is wrong — but those drivers don't support RGB101010, so this is fine in practice.

**Looks good** with the minor suggestion about enum ordering.

---

---
Generated by Claude Code Patch Reviewer