Claude review: drm/rcar-du: dsc: Add rudimentary Renesas R-Car V4H DSC driver

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

Patch Review

This is the core driver and has several items worth addressing:

**Bridge reference leak**: `of_drm_find_and_get_bridge()` increments the bridge refcount (as documented: "The refcount of the returned bridge is incremented. Use drm_bridge_put() when done with it."). The driver never calls `drm_bridge_put()` on `dsc->bridge.next_bridge`, leaking the reference. Compare with `rcar_lvds.c` which properly calls `drm_bridge_put(lvds->companion)` in its destroy callback for bridges obtained via `of_drm_find_and_get_bridge()`. This should be fixed.

```c
+	dsc->bridge.next_bridge = of_drm_find_and_get_bridge(remote);
+	of_node_put(remote);
+	if (!dsc->bridge.next_bridge)
+		return -EPROBE_DEFER;
```

**Use `devm_pm_runtime_enable`**: The probe/remove pair of `pm_runtime_enable` / `pm_runtime_disable` can be replaced with `devm_pm_runtime_enable(&pdev->dev)` in probe, eliminating the need for `rcar_dsc_remove()` entirely. This is the modern pattern and avoids ordering bugs.

```c
+static void rcar_dsc_remove(struct platform_device *pdev)
+{
+	pm_runtime_disable(&pdev->dev);
+}
```

**`-EPROBE_DEFER` without `dev_err_probe`**: When `of_drm_find_and_get_bridge()` returns NULL, the driver returns `-EPROBE_DEFER` silently. Using `return dev_err_probe(dev, -EPROBE_DEFER, "failed to find next bridge\n")` would suppress the message during deferred probing but log it if probe ultimately fails, which aids debugging.

**Unused MMIO mapping**: `dsc->mmio` is mapped but never accessed since this is bypass-mode only. This is fine for a rudimentary/initial driver, but it would be helpful to add a brief note in the commit message that the MMIO is mapped for future DSC encoding support. (No code change needed, just a documentation note.)

**`mode_valid` clock check**: The comment says "Really 400 Mpixel/s" but `mode->clock` is in kHz, and the check `mode->clock > 400000` limits to 400 MHz pixel clock. Whether 400 MHz clock equals 400 Mpixel/s depends on the pixel format — they're the same only for single-pixel-per-clock. If the hardware limit is truly 400 Mpixel/s and the DSC block always processes one pixel per clock, the check is correct. Worth confirming this assumption.

```c
+	if (mode->clock > 400000) /* Really 400 Mpixel/s */
+		return MODE_CLOCK_HIGH;
```

---
Generated by Claude Code Patch Reviewer