Claude review: drm: rz-du: Ensure correct suspend/resume ordering with VSP

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

Patch Review

**Correctness of the device link direction:** The call `device_link_add(rcdu->dev, vsp->vsp, DL_FLAG_STATELESS)` correctly makes the DU the consumer and the VSP the supplier. With `DL_FLAG_STATELESS`, the PM core ensures the supplier (VSP) is resumed before and suspended after the consumer (DU). This matches the commit message and comment.

**Cleanup concern — resource leak on `vsp1_du_init()` failure:**
The device link is created *before* calling `vsp1_du_init()`:

```c
+	vsp->link = device_link_add(rcdu->dev, vsp->vsp, DL_FLAG_STATELESS);
+	if (!vsp->link) {
+		dev_err(rcdu->dev, "Failed to create device link to VSP %s\n",
+			dev_name(vsp->vsp));
+		return -EINVAL;
+	}
+
 	ret = vsp1_du_init(vsp->vsp);
 	if (ret < 0)
 		return ret;
```

If `vsp1_du_init()` fails, the function returns an error. The cleanup action `rzg2l_du_vsp_cleanup` (registered via `drmm_add_action_or_reset` earlier) will eventually run and correctly delete the link since the patch adds the `device_link_del(vsp->link)` call there. So this is actually fine — the `drmm` cleanup handles it.

**Minor style observation:** The R-Car DU CMM code uses a local `struct device_link *link` variable rather than storing it in a struct, because the CMM links are never explicitly deleted (they live for the lifetime of the device). Here, you store `vsp->link` and explicitly delete it in cleanup, which is a reasonable design choice given the `drmm` managed lifecycle. However, with `DL_FLAG_STATELESS` device links, the link is automatically cleaned up when either the consumer or supplier device is unregistered. Since the DU device is the consumer and owns the lifecycle, the explicit `device_link_del` in cleanup is arguably redundant — but it's also harmless and makes the intent clear. No change needed.

**Include ordering:** `#include <linux/device.h>` is added in alphabetical order — correct.

**Header forward declaration:** `struct device_link;` is added in the correct alphabetical position in the header — correct.

**Struct field placement:** `struct device_link *link` is added after `struct device *vsp` which is a logical grouping — fine.

**Overall:** The patch is correct and clean. No blocking issues. It would be worth confirming with Laurent Pinchart whether he also planned to port the R-Car DU VSP device link (not just CMM) to the rz-du driver, since the R-Car DU VSP code itself doesn't appear to use device links currently — this patch adds functionality that goes beyond what the R-Car DU VSP has.

---
Generated by Claude Code Patch Reviewer