From: sashiko-bot@kernel.org
To: "Ville Syrjala" <ville.syrjala@linux.intel.com>,
intel-gfx@lists.freedesktop.org
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 03/10] drm/i915: Handle joined pipes inside intel_crtc_vblank_{on, off}()
Date: Fri, 30 Oct 2026 17:26:33 +0000 [thread overview]
Message-ID: <sashiko-outbox-191339@kernel.org> (raw)
In-Reply-To: <20261030171327.29829-4-ville.syrjala@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/i915: NULL state dereference in intel_crtc_vblank_off()
--
commit c6499a1bf58e345d4e50ee3b23d7821c66712bdd
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
drm/i915: Handle joined pipes inside intel_crtc_vblank_{on, off}()
This commit moves the joined-pipe iteration into intel_crtc_vblank_on()
and intel_crtc_vblank_off(), renaming the single-pipe helpers to
intel_pipe_vblank_on() and intel_pipe_vblank_off(). Callers are updated to
pass struct intel_atomic_state alongside the CRTC state.
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c b/drivers/gpu/drm/i915/display/icl_dsi.c
> index ea0cdb7822f39..381cdf7d5131c 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
[ ... ]
> @@ -1455,7 +1455,7 @@ static void gen11_dsi_post_disable(struct intel_atomic_state *state,
> struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
> struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
>
> - intel_crtc_vblank_off(old_crtc_state);
> + intel_crtc_vblank_off(state, old_crtc_state);
>
> /* step2d,e: disable transcoder and wait */
> gen11_dsi_disable_transcoder(encoder);
> diff --git a/drivers/gpu/drm/i915/display/intel_crt.c b/drivers/gpu/drm/i915/display/intel_crt.c
> index 5b8968197fbcf..b814b84c650fd 100644
> --- a/drivers/gpu/drm/i915/display/intel_crt.c
> +++ b/drivers/gpu/drm/i915/display/intel_crt.c
> @@ -265,7 +265,7 @@ static void hsw_post_disable_crt(struct intel_atomic_state *state,
> struct intel_display *display = to_intel_display(encoder);
> struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
>
> - intel_crtc_vblank_off(old_crtc_state);
> + intel_crtc_vblank_off(state, old_crtc_state);
>
> intel_disable_transcoder(old_crtc_state);
>
[ ... ]
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 10ed9bdfee763..a28f4a088e587 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
[ ... ]
> @@ -165,6 +165,34 @@ void intel_crtc_vblank_off(const struct intel_crtc_state *crtc_state)
> flush_work(&display->irq.vblank_notify_work);
> }
>
> +void intel_crtc_vblank_on(struct intel_atomic_state *state,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_display *display = to_intel_display(state);
> + struct intel_crtc *pipe_crtc;
> +
> + for_each_pipe_crtc_modeset_enable(display, pipe_crtc, crtc_state) {
> + const struct intel_crtc_state *pipe_crtc_state =
> + intel_atomic_get_new_crtc_state(state, pipe_crtc);
> +
> + intel_pipe_vblank_on(pipe_crtc_state);
> + }
> +}
> +
> +void intel_crtc_vblank_off(struct intel_atomic_state *state,
> + const struct intel_crtc_state *old_crtc_state)
> +{
> + struct intel_display *display = to_intel_display(state);
> + struct intel_crtc *pipe_crtc;
> +
> + for_each_pipe_crtc_modeset_disable(display, pipe_crtc, old_crtc_state) {
> + const struct intel_crtc_state *old_pipe_crtc_state =
> + intel_atomic_get_old_crtc_state(state, pipe_crtc);
> +
> + intel_pipe_vblank_off(old_pipe_crtc_state);
> + }
> +}
[Severity: High]
Can state be NULL when intel_crtc_vblank_off() is called from
encoder->post_disable()?
During initial hardware readout or resume in
intel_modeset_setup_hw_state(), intel_sanitize_encoder() disables an
encoder whose connector is active while its pipe is inactive by invoking
the disable hooks with a NULL atomic state:
drivers/gpu/drm/i915/display/intel_modeset_setup.c:intel_sanitize_encoder() {
...
if (connector && !has_active_crtc) {
...
if (crtc_state) {
...
/* FIXME NULL atomic state passed! */
if (encoder->disable)
encoder->disable(NULL, encoder, crtc_state,
connector->base.state);
if (encoder->post_disable)
encoder->post_disable(NULL, encoder, crtc_state,
connector->base.state);
}
}
}
Previously, gen11_dsi_post_disable(), intel_dsi_post_disable() (on
Broxton and Geminilake), and hsw_post_disable_crt() did not dereference
state and passed old_crtc_state directly to intel_crtc_vblank_off(). With
this change, those callbacks pass state = NULL to intel_crtc_vblank_off(),
which dereferences state in both to_intel_display(state) and
intel_atomic_get_old_crtc_state(state, pipe_crtc).
Would it make sense to keep using intel_pipe_vblank_off(old_crtc_state) in
the non-joiner post_disable callbacks, or handle a NULL state inside
intel_crtc_vblank_off()?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261030171327.29829-1-ville.syrjala@linux.intel.com?part=3
next prev parent reply other threads:[~2026-10-30 17:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 17:13 [PATCH 00/10] drm/i915: Enable vblanks after the timing generator has started Ville Syrjala
2026-10-30 17:13 ` [PATCH 01/10] drm/i915: Disable port sync if VRR is enabled Ville Syrjala
2026-10-30 17:13 ` [PATCH 02/10] drm/i915: Do intel_crtc_vblank_on() later on HSW+ Ville Syrjala
2026-10-30 17:13 ` [PATCH 03/10] drm/i915: Handle joined pipes inside intel_crtc_vblank_{on, off}() Ville Syrjala
2026-10-30 17:26 ` sashiko-bot [this message]
2026-10-30 17:49 ` Ville Syrjälä
2026-10-30 17:13 ` [PATCH 04/10] Revert "drm/i915/display: Avoid stale PIPE_SCANLINE values after crtc_enable" Ville Syrjala
2026-10-30 17:13 ` [PATCH 05/10] drm/i915: Fix intel_crtc_vblank_on() with port sync Ville Syrjala
2026-10-30 17:13 ` [PATCH 06/10] drm/i915: Wait for timing generator to start in intel_crtc_vblank_on() on HSW+ Ville Syrjala
2026-10-30 17:32 ` sashiko-bot
2026-10-30 18:07 ` Ville Syrjälä
2026-10-30 17:13 ` [PATCH 07/10] drm/i915: Reduce the sleep inside pipe_scanline_is_moving() Ville Syrjala
2026-10-30 17:13 ` [PATCH 08/10] drm/i915: Document timing generator start/stop behaviour on HSW+ Ville Syrjala
2026-10-30 17:13 ` [PATCH 09/10] drm/i915: Fix FEC wait with port sync on pre-LNL Ville Syrjala
2026-10-30 17:29 ` sashiko-bot
2026-10-30 17:13 ` [PATCH 10/10] drm/i915: Allow joiner with port sync Ville Syrjala
2026-10-30 17:38 ` sashiko-bot
2026-10-30 18:23 ` Ville Syrjälä
2026-10-30 17:20 ` ✗ CI.checkpatch: warning for drm/i915: Enable vblanks after the timing generator has started Patchwork
2026-10-30 17:23 ` ✓ CI.KUnit: success " Patchwork
2026-10-30 17:59 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-30 18:03 ` ✓ i915.CI.BAT: " Patchwork
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=sashiko-outbox-191339@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=ville.syrjala@linux.intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.