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 1/9] drm/i915/de: Introduce dislay->mmio and intel_de_init()
Date: Wed, 04 Nov 2026 22:31:47 +0000 [thread overview]
Message-ID: <sashiko-outbox-198229@kernel.org> (raw)
In-Reply-To: <20261104221842.18799-2-ville.syrjala@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/i915/de: NULL display->mmio.uncore when intel_de_init() is skipped
--
commit 0c47f694d22974ac99844e39b462f72389dd014b
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
drm/i915/de: Introduce dislay->mmio and intel_de_init()
This commit adds a display->mmio struct and intel_de_init() to initialize
display->mmio.uncore, and updates __to_uncore() to return display->mmio.uncore
instead of calling to_intel_uncore(display->drm).
[ ... ]
> diff --git a/drivers/gpu/drm/i915/display/intel_de.h b/drivers/gpu/drm/i915/display/intel_de.h
> index d0a239a369807..f1135ee5071b4 100644
> --- a/drivers/gpu/drm/i915/display/intel_de.h
> +++ b/drivers/gpu/drm/i915/display/intel_de.h
> @@ -14,9 +14,11 @@
>
> static inline struct intel_uncore *__to_uncore(struct intel_display *display)
> {
> - return to_intel_uncore(display->drm);
> + return display->mmio.uncore;
> }
[ ... ]
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c b/drivers/gpu/drm/i915/display/intel_display_device.c
> index c74256359c253..f1bd1252a9602 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> @@ -1798,6 +1798,13 @@ static void __intel_display_device_info_runtime_init(struct intel_display *displ
> struct intel_display_runtime_info *display_runtime = DISPLAY_RUNTIME_INFO(display);
> enum pipe pipe;
>
> + /*
> + * TODO end of intel_display_device_probe() would be a more
> + * logical place, but at the moment i915 calls that super
> + * early when things aren't fully set up yet.
> + */
> + intel_de_init(display);
[Severity: High]
Can this leave display->mmio.uncore NULL and cause a NULL pointer dereference
when HAS_DISPLAY(display) is already false before runtime init?
In drivers/gpu/drm/i915/display/intel_display_device.c,
intel_display_device_info_runtime_init() only calls
__intel_display_device_info_runtime_init() when HAS_DISPLAY(display) is true:
void intel_display_device_info_runtime_init(struct intel_display *display)
{
if (HAS_DISPLAY(display))
__intel_display_device_info_runtime_init(display);
On devices where intel_display_device_probe() sets DISPLAY_INFO() to
no_display—such as Ivybridge Quanta server SKUs (INTEL_IVB_Q_IDS via
has_no_display()), PCI IDs without an entry in intel_display_ids like Arctic
Sound-M (INTEL_ATS_M_IDS where find_platform_desc() returns NULL), or GMD_ID
platforms (INTEL_MTL_IDS / INTEL_ARL_IDS) where probe_gmdid_display() reads 0
from GMD_ID_DISPLAY—HAS_DISPLAY(display) is false and
__intel_display_device_info_runtime_init() is skipped.
Because __to_uncore(display) in drivers/gpu/drm/i915/display/intel_de.h now
returns display->mmio.uncore instead of computing
to_intel_uncore(display->drm), any subsequent unconditional intel_de_*() call
will pass a NULL struct intel_uncore pointer to intel_uncore_read*() or
intel_uncore_write*():
1. On INTEL_IVB_Q_IDS, ilk_irq_handler() in drivers/gpu/drm/i915/i915_irq.c
unconditionally calls ilk_display_irq_master_disable() and
ilk_display_irq_master_enable() in
drivers/gpu/drm/i915/display/intel_display_irq.c on every interrupt, which
call intel_de_read_fw(display, DEIER) and intel_de_write_fw(display, DEIER,
...).
2. On INTEL_ATS_M_IDS and headless GMD_ID platforms, gen11_irq_handler() and
dg1_irq_handler() unconditionally call gen11_gu_misc_irq_ack() in
drivers/gpu/drm/i915/display/intel_display_irq.c when GEN11_GU_MISC_IRQ is
set, which calls intel_de_read_fw(display, GEN11_GU_MISC_IIR) and
intel_de_write_fw(display, GEN11_GU_MISC_IIR, iir).
3. During system resume, i915_drm_resume() in
drivers/gpu/drm/i915/i915_driver.c unconditionally calls
intel_gmbus_reset(display) in drivers/gpu/drm/i915/display/intel_gmbus.c,
which calls intel_de_write_fw(display, GMBUS0(display), 0) and
intel_de_write_fw(display, GMBUS4(display), 0).
Should intel_de_init(display) be called unconditionally at the start of
intel_display_device_info_runtime_init() before the HAS_DISPLAY(display)
check?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261104221842.18799-1-ville.syrjala@linux.intel.com?part=1
next prev parent reply other threads:[~2026-11-04 22:32 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 [this message]
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
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-198229@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.