Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm/malidp: runtime PM usage counter underflow in malidp_crtc_atomic_disable() --
commit 3492dcc2c28d3962cf4a64dc34d1fb164aaf6580 Author: Wentao Liang <[email protected]> drm/mali-dp: Fix runtime PM leak in malidp_crtc_atomic_enable() This patch drops the runtime PM reference with pm_runtime_put_noidle() on the resume failure path in malidp_crtc_atomic_enable(). This is intended to fix a reference leak when pm_runtime_get_sync() fails. > diff --git a/drivers/gpu/drm/arm/malidp_crtc.c > b/drivers/gpu/drm/arm/malidp_crtc.c > index 157ff148efe7a..ec7b9db8b0b45 100644 > --- a/drivers/gpu/drm/arm/malidp_crtc.c > +++ b/drivers/gpu/drm/arm/malidp_crtc.c > @@ -56,6 +56,7 @@ static void malidp_crtc_atomic_enable(struct drm_crtc *crtc, > > if (err < 0) { > DRM_DEBUG_DRIVER("Failed to enable runtime power management: > %d\n", err); > + pm_runtime_put_noidle(crtc->dev->dev); [Severity: High] Could this addition cause a runtime PM usage counter underflow when the CRTC is later disabled? Because malidp_crtc_atomic_enable() returns void, the DRM core still considers the CRTC active even if it returns early on error here. When the CRTC is later disabled, malidp_crtc_atomic_disable() will be unconditionally called, which executes its own pm_runtime_put(): drivers/gpu/drm/arm/malidp_crtc.c:malidp_crtc_atomic_disable() { ... clk_disable_unprepare(hwdev->pxlclk); pm_runtime_put(crtc->dev->dev); } If we drop the PM reference here on the error path, wouldn't the later call to pm_runtime_put() in malidp_crtc_atomic_disable() result in a double-put and underflow the PM usage counter? > return; > } > -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
