From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm: rz-du: Ensure correct suspend/resume ordering with VSP
Date: Wed, 25 Mar 2026 06:34:36 +1000
Message-ID: <review-patch1-20260324180512.2277875-1-tommaso.merciai.xr@bp.renesas.com>
In-Reply-To: <20260324180512.2277875-1-tommaso.merciai.xr@bp.renesas.com>
References: <20260324180512.2277875-1-tommaso.merciai.xr@bp.renesas.com> <20260324180512.2277875-1-tommaso.merciai.xr@bp.renesas.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Patch Review

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

**Cleanup concern =E2=80=94 resource leak on `vsp1_du_init()` failure:**
The device link is created *before* calling `vsp1_du_init()`:

```c
+	vsp->link =3D 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 =3D vsp1_du_init(vsp->vsp);
 	if (ret < 0)
 		return ret;
```

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

**Minor style observation:** The R-Car DU CMM code uses a local `struct dev=
ice_link *link` variable rather than storing it in a struct, because the CM=
M links are never explicitly deleted (they live for the lifetime of the dev=
ice). Here, you store `vsp->link` and explicitly delete it in cleanup, whic=
h 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 D=
U device is the consumer and owns the lifecycle, the explicit `device_link_=
del` in cleanup is arguably redundant =E2=80=94 but it's also harmless and =
makes the intent clear. No change needed.

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

**Header forward declaration:** `struct device_link;` is added in the corre=
ct alphabetical position in the header =E2=80=94 correct.

**Struct field placement:** `struct device_link *link` is added after `stru=
ct device *vsp` which is a logical grouping =E2=80=94 fine.

**Overall:** The patch is correct and clean. No blocking issues. It would b=
e worth confirming with Laurent Pinchart whether he also planned to port th=
e 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 =E2=80=
=94 this patch adds functionality that goes beyond what the R-Car DU VSP ha=
s.

---
Generated by Claude Code Patch Reviewer