Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm: access after clock disable in vs_crtc_atomic_disable() --
commit 4d2b1621cdee94c9390817d0548d0b254e003aa6 Author: Joey Lu <[email protected]> drm/verisilicon: introduce per-variant hardware ops table This commit introduces a per-variant hardware operations table (vs_dc_funcs) for the Verisilicon display controller driver. It extracts DC8200-specific hardware operations and updates shared code to dispatch through this vtable to better support different hardware variants. > diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c > b/drivers/gpu/drm/verisilicon/vs_crtc.c > index c24c1588cbe69..6033662dd9221 100644 > --- a/drivers/gpu/drm/verisilicon/vs_crtc.c > +++ b/drivers/gpu/drm/verisilicon/vs_crtc.c [ ... ] > @@ -30,6 +53,9 @@ static void vs_crtc_atomic_disable(struct drm_crtc *crtc, > drm_crtc_vblank_off(crtc); > > clk_disable_unprepare(dc->pix_clk[output]); > + > + if (dc->funcs->crtc_disable_ex) > + dc->funcs->crtc_disable_ex(dc, output); [Severity: High] Does this access hardware registers after their clock is gated? In vs_crtc_atomic_disable(), the pixel clock is disabled via clk_disable_unprepare() just before calling the hardware-specific disable hook crtc_disable_ex(). If the hook accesses the hardware block after its clock is already powered down, it typically leads to asynchronous external aborts, system hangs, or MMIO bus faults. Should the clock be kept enabled until after crtc_disable_ex() finishes, similar to how vs_crtc_atomic_enable() properly enables the clock before calling crtc_enable_ex()? > } > > static void vs_crtc_atomic_enable(struct drm_crtc *crtc, [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
