dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Joey Lu" <a0987203069@gmail.com>
Cc: dri-devel@lists.freedesktop.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH v6 6/6] drm/verisilicon: extend Kconfig to support ARCH_MA35 platforms
Date: Tue, 08 Sep 2026 10:25:13 +0000	[thread overview]
Message-ID: <20260908102514.2DC421F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260908092840.225220-7-a0987203069@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The CRTC pixel clock is disabled before the hardware is instructed to disable the CRTC.
--

commit c35af4d919e849e303afa29d897c4d1581720138
Author: Joey Lu <a0987203069@gmail.com>

drm/verisilicon: introduce per-variant hardware ops table

The DC8200 and DCUltraLite share a broadly similar register layout but
differ in how the bridge, CRTC, primary plane and IRQ paths are driven.
This commit introduces a vs_dc_funcs vtable so each variant can supply
its own implementation without scattering conditionals across multiple files.

> diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c b/drivers/gpu/drm/verisilicon/vs_crtc.c
> index 0b8a35d09cd2e..1c4aac7086694 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]
Are hardware registers written after the pixel clock is disabled here?

In vs_crtc_atomic_disable(), dc->funcs->crtc_disable_ex() executes
out-of-order, writing to MMIO registers after the associated pixel clock has
been disabled via clk_disable_unprepare().

Writing to hardware registers after disabling the pixel clock can cause bus
hangs (asynchronous external aborts) resulting in kernel panics, or silently
fail to latch the register value, leaving the hardware in an inconsistent
state.

This sequence can be triggered by local userspace through DRM atomic mode
setting ioctls when the CRTC is disabled, such as when turning off the
screen or performing a mode switch.

Could the hardware disable callback be moved before the clock is disabled to
correctly mirror the enable sequence?

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908092840.225220-1-a0987203069@gmail.com?part=6

      reply	other threads:[~2026-09-08 10:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08  9:28 [PATCH v6 0/6] drm/verisilicon: add Nuvoton MA35D1 DCU Lite support Joey Lu
2026-09-08  9:28 ` [PATCH v6 1/6] dt-bindings: display: verisilicon, dc: add support for nuvoton, ma35d1-dcu Joey Lu
2026-09-08  9:36   ` [PATCH v6 1/6] dt-bindings: display: verisilicon,dc: add support for nuvoton,ma35d1-dcu sashiko-bot
2026-09-08 17:55   ` [PATCH v6 1/6] dt-bindings: display: verisilicon, dc: " Conor Dooley
2026-09-09  5:44   ` [PATCH v6 1/6] dt-bindings: display: verisilicon,dc: " Icenowy Zheng
2026-09-10  1:52     ` [PATCH v6 1/6] dt-bindings: display: verisilicon, dc: " Joey Lu
2026-09-10  7:08       ` [PATCH v6 1/6] dt-bindings: display: verisilicon,dc: " Icenowy Zheng
2026-09-08  9:28 ` [PATCH v6 2/6] drm/verisilicon: add register-level macros for DC8000 Joey Lu
2026-09-08  9:28 ` [PATCH v6 3/6] drm/verisilicon: introduce per-variant hardware ops table Joey Lu
2026-09-08  9:51   ` sashiko-bot
2026-09-08  9:28 ` [PATCH v6 4/6] drm/verisilicon: add DC8000 (DCUltraLite) display controller support Joey Lu
2026-09-08 10:04   ` sashiko-bot
2026-09-10  7:25   ` Icenowy Zheng
2026-09-08  9:28 ` [PATCH v6 5/6] drm/verisilicon: add DCUltraLite chip identity to HWDB Joey Lu
2026-09-08 10:15   ` sashiko-bot
2026-09-08  9:28 ` [PATCH v6 6/6] drm/verisilicon: extend Kconfig to support ARCH_MA35 platforms Joey Lu
2026-09-08 10:25   ` sashiko-bot [this message]

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=20260908102514.2DC421F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=a0987203069@gmail.com \
    --cc=conor+dt@kernel.org \
    --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