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 7/9] drm/i915/de: Move unclaimed mmio detection into display code
Date: Wed, 04 Nov 2026 22:36:37 +0000 [thread overview]
Message-ID: <sashiko-outbox-198239@kernel.org> (raw)
In-Reply-To: <20261104221842.18799-8-ville.syrjala@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] drm/i915/de: NULL deref on displayless devices in unclaimed MMIO checks
- [Medium] drm/i915/de: intel_de_init() enables FPGA_DBG check on Ivy Bridge
- [Medium] drm/i915/de: unclaimed MMIO status is not cleared on initialization
- [Low] drm/i915/display: unused mmio.mmio_debug field in struct intel_display
--
commit 74c572411ef669251a5e2e347d14a7771407e433
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
drm/i915/de: Move unclaimed mmio detection into display code
This commit moves the FPGA_DBG and CLAIM_ER unclaimed MMIO access detection
from intel_uncore into the display code, protecting the tracking state with
display->mmio.lock.
> diff --git a/drivers/gpu/drm/i915/display/intel_de.c b/drivers/gpu/drm/i915/display/intel_de.c
> index 8b7a4e696ff96..0a51105e0fbad 100644
> --- a/drivers/gpu/drm/i915/display/intel_de.c
> +++ b/drivers/gpu/drm/i915/display/intel_de.c
[ ... ]
> @@ -163,8 +164,127 @@ u16 intel_de_read16(struct intel_display *display, intel_reg_t reg)
[ ... ]
> +bool intel_de_unclaimed_mmio_detected(struct intel_display *display)
> +{
> + bool ret;
> +
> + if (!display->mmio.funcs->check_for_unclaimed_mmio)
> + return false;
> +
> + spin_lock_irq(&display->mmio.lock);
> + ret = display->mmio.funcs->check_for_unclaimed_mmio(display);
> + spin_unlock_irq(&display->mmio.lock);
> +
> + return ret;
> +}
> +
> +bool intel_de_arm_unclaimed_mmio_detection(struct intel_display *display)
> +{
> + bool ret = false;
> +
> + if (!display->mmio.funcs->check_for_unclaimed_mmio)
> + return false;
[Severity: High]
Can intel_de_unclaimed_mmio_detected() and
intel_de_arm_unclaimed_mmio_detection() dereference a NULL display->mmio.funcs
pointer on devices without display?
On displayless devices where intel_display_device_probe() takes the no_display
path (such as INTEL_IVB_Q_IDS, INTEL_ATS_M_IDS, or GMD_ID platforms where
GMD_ID_DISPLAY reads 0), HAS_DISPLAY(display) is false. During probe,
intel_display_device_info_runtime_init() skips
__intel_display_device_info_runtime_init():
drivers/gpu/drm/i915/display/intel_display_device.c:
intel_display_device_info_runtime_init() {
if (HAS_DISPLAY(display))
__intel_display_device_info_runtime_init(display);
Because intel_de_init() is only called from
__intel_display_device_info_runtime_init(), display->mmio.funcs remains NULL
and display->mmio.lock is never initialized.
Later, i915_drm_resume_early(), i915_pm_runtime_suspend(), and
i915_pm_runtime_resume() unconditionally call
intel_display_driver_mmio_resume_early() and
intel_display_driver_mmio_suspend_late(), which call
intel_de_unclaimed_mmio_detected() and intel_de_arm_unclaimed_mmio_detection()
and dereference display->mmio.funcs.
Additionally, if HAS_DISPLAY(display) is initially true so intel_de_init()
sets display->mmio.funcs = &ivb_mmio_funcs, and
__intel_display_device_info_runtime_init() subsequently jumps to
display_fused_off, display->mmio.funcs remains set while HAS_DISPLAY(display)
becomes false, causing suspend and resume to access FPGA_DBG even though
display is fused off.
Should intel_de_init() be called unconditionally (or display->mmio.funcs be
checked / reset when display is fused off), and should
intel_display_driver_mmio_suspend_late() and
intel_display_driver_mmio_resume_early() check HAS_DISPLAY(display)?
[ ... ]
> @@ -304,7 +470,11 @@ void intel_de_init(struct intel_display *display)
> spin_lock_init(&display->mmio.lock);
>
> if (driver_is_i915()) {
> - if (display->platform.valleyview || display->platform.cherryview)
> + if (display->platform.valleyview || display->platform.cherryview)
> + display->mmio.funcs = &vlv_mmio_funcs;
> + else if (DISPLAY_VER(display) >= 7)
> + display->mmio.funcs = &ivb_mmio_funcs;
> + else if (DISPLAY_VER(display) >= 6)
> display->mmio.funcs = &snb_mmio_funcs;
> else
> display->mmio.funcs = &i9xx_mmio_funcs;
[Severity: Medium]
Does checking DISPLAY_VER(display) >= 7 in intel_de_init() unintentionally
enable FPGA_DBG unclaimed MMIO checks on Ivy Bridge?
Previously, intel_uncore_init_mmio() gated FPGA_DBG unclaimed MMIO detection
on HAS_FPGA_DBG_UNCLAIMED(display). In
drivers/gpu/drm/i915/display/intel_display_device.c, has_fpga_dbg is set on
hsw_desc and bdw_desc onwards, whereas ivb_display has ip.ver = 7 and
has_fpga_dbg = 0. Checking DISPLAY_VER(display) >= 7 assigns ivb_mmio_funcs to
Ivy Bridge as well, and leaves HAS_FPGA_DBG_UNCLAIMED(display) unused.
Should this check HAS_FPGA_DBG_UNCLAIMED(display) instead?
> @@ -314,4 +484,7 @@ void intel_de_init(struct intel_display *display)
> else
> display->mmio.funcs = &i9xx_mmio_funcs;
> }
> +
> + if (display->mmio.funcs->check_for_unclaimed_mmio)
> + display->mmio.unclaimed_mmio_check = 1;
> }
[Severity: Medium]
Previously, intel_uncore_init_mmio() cleared any stale unclaimed MMIO bit left
set by BIOS or pre-boot firmware during initialization:
/* clear out unclaimed reg detection bit */
if (intel_uncore_unclaimed_mmio(uncore))
drm_dbg(&i915->drm, "unclaimed mmio detected on uncore init, clearing\n");
With that removed and not replaced in intel_de_init(), if mmio_debug is
disabled by default, won't a stale FPGA_DBG_RM_NOCLAIM or CLAIM_ER bit from
boot firmware remain latched until intel_de_arm_unclaimed_mmio_detection()
runs at the end of the first modeset or in
intel_display_driver_mmio_suspend_late(), triggering a false-positive error or
falsely arming oneshot mmio_debug reporting?
> diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h b/drivers/gpu/drm/i915/display/intel_display_core.h
> index aded2af8c92a6..cb18ee040b5d6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> @@ -539,11 +539,18 @@ struct intel_display {
> * serializes all display register accesses done
> * using intel_de_{read,write}(), but not those
> * done using intel_de_{read,write}_fw().
> + *
> + * The lock also protects mmio.mmio_debug and
> + * mmio.unclaimed_mmio_check.
> */
> spinlock_t lock;
>
> struct intel_uncore *uncore;
> const struct intel_mmio_funcs *funcs;
> +
> + /* protected by mmio.lock */
> + int mmio_debug;
> + int unclaimed_mmio_check;
> } mmio;
[Severity: Low]
This isn't a bug, but display->mmio.mmio_debug is never used since
check_unclaimed_mmio_pre(), check_unclaimed_mmio_post(), and
intel_de_arm_unclaimed_mmio_detection() all use display->params.mmio_debug.
Should mmio.mmio_debug be dropped from struct intel_display?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261104221842.18799-1-ville.syrjala@linux.intel.com?part=7
next prev parent reply other threads:[~2026-11-04 22:36 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 22:18 [PATCH 0/9] drm/i915/de: Work towards uncore elimination Ville Syrjala
2026-11-04 22:18 ` [PATCH 1/9] drm/i915/de: Introduce dislay->mmio and intel_de_init() Ville Syrjala
2026-11-04 22:31 ` sashiko-bot
2026-11-05 8:58 ` Jani Nikula
2026-11-05 20:03 ` Ville Syrjälä
2026-11-04 23:29 ` Michał Grzelak
2026-11-04 22:18 ` [PATCH 2/9] drm/i915/de: Convert intel_de_{read,write}() into vfuncs Ville Syrjala
2026-11-06 14:50 ` Jani Nikula
2026-11-06 15:35 ` Ville Syrjälä
2026-11-04 22:18 ` [PATCH 3/9] drm/i915/de: Introduce mmio read/write templates Ville Syrjala
2026-11-04 23:32 ` Michał Grzelak
2026-11-06 14:52 ` Jani Nikula
2026-11-06 16:03 ` Ville Syrjälä
2026-11-04 22:18 ` [PATCH 4/9] drm/i915/de: Eliminate runtime overhead from DMC wakelock on pre-LNL platforms Ville Syrjala
2026-11-06 14:53 ` Jani Nikula
2026-11-04 22:18 ` [PATCH 5/9] drm/i915/de: Introduce display->mmio.lock Ville Syrjala
2026-11-04 22:35 ` sashiko-bot
2026-11-05 9:32 ` Jani Nikula
2026-11-05 13:43 ` Ville Syrjälä
2026-11-05 13:47 ` Jani Nikula
2026-11-06 14:55 ` Jani Nikula
2026-11-04 22:18 ` [PATCH 6/9] drm/i915/uncore: Don't meddle with mmio debug upon user forcewake Ville Syrjala
2026-11-06 14:58 ` Jani Nikula
2026-11-04 22:18 ` [PATCH 7/9] drm/i915/de: Move unclaimed mmio detection into display code Ville Syrjala
2026-11-04 22:36 ` sashiko-bot [this message]
2026-11-06 16:19 ` Ville Syrjälä
2026-11-06 16:39 ` Jani Nikula
2026-11-06 17:24 ` Ville Syrjälä
2026-11-04 22:18 ` [PATCH 8/9] drm/i915/de: Stop using intel_uncore_{read,write}() Ville Syrjala
2026-11-06 15:37 ` Jani Nikula
2026-11-06 15:55 ` Ville Syrjälä
2026-11-04 22:18 ` [PATCH 9/9] drm/xe: Nuke the intel_uncore_{read,write}() wrappers Ville Syrjala
2026-11-06 15:38 ` [PATCH 9/9] drm/xe: Nuke the intel_uncore_{read, write}() wrappers Jani Nikula
2026-11-05 0:01 ` ✗ CI.checkpatch: warning for drm/i915/de: Work towards uncore elimination Patchwork
2026-11-05 0:03 ` ✓ CI.KUnit: success " Patchwork
2026-11-05 0:40 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-05 2:14 ` ✓ i915.CI.BAT: " Patchwork
2026-11-05 4:38 ` ✓ i915.CI.Full: " Patchwork
2026-11-05 7:10 ` ✗ CI.checkpatch: warning for drm/i915/de: Work towards uncore elimination (rev2) Patchwork
2026-11-05 7:13 ` ✓ CI.KUnit: success " Patchwork
2026-11-05 7:47 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-06 1:17 ` ✓ Xe.CI.FULL: " 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-198239@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.