Re: [PATCH v7 3/7] drm/verisilicon: introduce per-variant hardware ops table

[sashiko-bot@kernel.org]

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 <a0987203069@gmail.com>

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/20260918030125.315978-1-a0987203069@gmail.com?part=3