Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Sleeping functions clk_set_parent() and mutex_lock() called from CRTC atomic enable callback. -- commit afbd808f729085c5fb27d8d2795c3ac8b9bd1609 Author: Cristian Ciocaltea <[email protected]> drm/rockchip: vop2: Consolidate HDMI PHY PLL clock parent switch This commit refactors the DCLK parent switch logic for HDMI0 and HDMI1 PHY PLLs into a single shared code path instead of repeating the parent selection and clock switch for each endpoint. > 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 > @@ -1964,42 +1964,34 @@ static void vop2_crtc_atomic_enable(struct drm_crtc > *crtc, [ ... ] > + if (pll_hdmiphy) { > + if (!vp->dclk_src) > + vp->dclk_src = clk_get_parent(vp->dclk); > + > + ret = clk_set_parent(vp->dclk, pll_hdmiphy); [Severity: High] This is a pre-existing issue, but does calling clk_set_parent() in this function violate atomic context rules? The vop2_crtc_atomic_enable() callback runs in an atomic context during a display modeset, where sleeping is strictly forbidden by DRM subsystem guidelines. Because clk_set_parent() might sleep, could this lead to system instability, potential deadlocks, or kernel warnings when reconfiguring the display? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=9
