From: sashiko-bot@kernel.org
To: "Cristian Ciocaltea" <cristian.ciocaltea@collabora.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4 02/14] drm/rockchip: vop2: Fix resource leak on vop2_enable() error path
Date: Wed, 02 Sep 2026 23:03:27 +0000 [thread overview]
Message-ID: <20260902230327.C326D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260903-dw-hdmi-qp-yuv-v4-2-fb45bf4147eb@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Use of sleeping functions in an atomic context path.
--
commit 3156fa20e2cac505ec1966277bb361639a86a353
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
drm/rockchip: vop2: Fix resource leak on vop2_enable() error path
This commit modifies vop2_enable() to return an int and gracefully unwind
resources such as clocks and runtime PM references if initialization steps
like rockchip_drm_dma_attach_device() fail. It addresses a resource leak
where previously the function returned void without disabling clocks or
dropping the PM reference on error.
Link: https://lore.kernel.org/all/20260623202043.8BFE21F000E9@smtp.kernel.org/
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
[ ... ]
> @@ -932,6 +938,17 @@ static void vop2_enable(struct vop2 *vop2)
> VOP2_INT_BUS_ERRPR << 16 | VOP2_INT_BUS_ERRPR);
> vop2_writel(vop2, RK3568_SYS1_INT_EN,
> VOP2_INT_BUS_ERRPR << 16 | VOP2_INT_BUS_ERRPR);
> +
> + return 0;
> +
> +err_detach_dma:
> + rockchip_drm_dma_detach_device(vop2->drm, vop2->dev);
> +err_disable_clks:
> + vop2_core_clks_disable_unprepare(vop2);
> +err_put_pm:
> + pm_runtime_put_sync(vop2->dev);
[Severity: High]
This is a pre-existing issue, but is it safe to execute a sleeping function
here?
The DRM subsystem guidelines indicate that CRTC atomic_enable callbacks are
atomic context paths where sleeping is strictly forbidden. Since vop2_enable()
is called from the vop2_crtc_atomic_enable() callback, wouldn't executing
pm_runtime_put_sync() (as well as clk_prepare_enable() and
pm_runtime_resume_and_get() earlier in this function) cause system panics
such as scheduling while atomic or deadlocks during a display bring-up
or modeset?
> +
> + return ret;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260903-dw-hdmi-qp-yuv-v4-0-fb45bf4147eb@collabora.com?part=2
next prev parent reply other threads:[~2026-09-02 23:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 22:54 [PATCH v4 00/14] Support 10-bit YUV422 and 8/10-bit YUV420 color format on DW HDMI QP Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 01/14] dt-bindings: display: vop2: Add missing reset properties Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 02/14] drm/rockchip: vop2: Fix resource leak on vop2_enable() error path Cristian Ciocaltea
2026-09-02 23:03 ` sashiko-bot [this message]
2026-09-02 22:54 ` [PATCH v4 03/14] drm/rockchip: vop2: Balance state on atomic_enable() error paths Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 04/14] drm/rockchip: vop2: Send pending event when atomic_enable() fails Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 05/14] drm/rockchip: vop2: Avoid division by zero when computing max_dclk Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 06/14] drm/rockchip: vop2: Fix VOP2_MAX_DCLK_RATE overflow on 32-bit Cristian Ciocaltea
2026-09-02 23:01 ` sashiko-bot
2026-09-02 22:54 ` [PATCH v4 07/14] drm/rockchip: vop2: Reset AXI and DCLK to improve robustness Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 08/14] drm/rockchip: vop2: Avoid DCLK source switch for 10-bit YUV422 output Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 09/14] drm/rockchip: vop2: Consolidate HDMI PHY PLL clock parent switch Cristian Ciocaltea
2026-09-02 23:01 ` sashiko-bot
2026-09-02 22:54 ` [PATCH v4 10/14] drm/rockchip: vop2: Switch to enum vop_csc_format Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 11/14] drm/bridge: dw-hdmi-qp: Log resolution and refresh rate in atomic_enable() Cristian Ciocaltea
2026-09-02 22:54 ` [PATCH v4 12/14] drm/rockchip: dw_hdmi_qp: Support 10-bit YUV422 output format Cristian Ciocaltea
2026-09-02 23:06 ` sashiko-bot
2026-09-02 22:54 ` [PATCH v4 13/14] drm/rockchip: dw_hdmi_qp: Enable YUV420 " Cristian Ciocaltea
2026-09-02 23:08 ` sashiko-bot
2026-09-02 22:54 ` [PATCH v4 14/14] arm64: dts: rockchip: Add RK3588 VOP2 resets Cristian Ciocaltea
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260902230327.C326D1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=cristian.ciocaltea@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox