From: Imre Deak <imre.deak@intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: <intel-gfx@lists.freedesktop.org>,
<intel-xe@lists.freedesktop.org>,
Mohammed Thasleem <mohammed.thasleem@intel.com>,
<stable@vger.kernel.org>
Subject: Re: [PATCH] drm/i915/dmc: fix an unlikely NULL pointer deference at probe
Date: Tue, 2 Dec 2025 23:24:42 +0200 [thread overview]
Message-ID: <aS9ZGmXG_n0IXv-N@ideak-desk> (raw)
In-Reply-To: <20251202183950.2450315-1-jani.nikula@intel.com>
On Tue, Dec 02, 2025 at 08:39:50PM +0200, Jani Nikula wrote:
> intel_dmc_update_dc6_allowed_count() oopses when DMC hasn't been
> initialized, and dmc is thus NULL.
>
> That would be the case when the call path is
> intel_power_domains_init_hw() -> {skl,bxt,icl}_display_core_init() ->
> gen9_set_dc_state() -> intel_dmc_update_dc6_allowed_count(), as
> intel_power_domains_init_hw() is called *before* intel_dmc_init().
>
> However, gen9_set_dc_state() calls intel_dmc_update_dc6_allowed_count()
> conditionally, depending on the current and target DC states. At probe,
> the target is disabled, but if DC6 is enabled, the function is called,
> and an oops follows. Apparently it's quite unlikely that DC6 is enabled
> at probe, as we haven't seen this failure mode before.
>
> Add NULL checks and switch the dmc->display references to just display.
>
> Fixes: 88c1f9a4d36d ("drm/i915/dmc: Create debugfs entry for dc6 counter")
> Cc: Mohammed Thasleem <mohammed.thasleem@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Cc: <stable@vger.kernel.org> # v6.16+
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>
> ---
>
> Rare case, but this may also throw off the rc6 counting in debugfs when
> it does happen.
Yes, I missed the case where the driver is being loaded while DC6 is
enabled, this is what happens for the reporter:
i915 0000:00:04.0: [drm] *ERROR* DC state mismatch (0x0 -> 0x2)
That's odd, as DC6 requires the DMC firmware, which - if it's indeed
loaded by BIOS for instance - will be overwritten by the driver, not a
well specified sequence (even though the driver is trying to handle it
correctly by disabling any active firmware handler).
But as you pointed out this would also throw off the cooked-up DC6
counter tracking, so could instead the counter update depend on the
driver's DC state instead of the HW state? I.e. set
gen9_set_dc_state()/dc6_was_enabled,
intel_dmc_get_dc6_allowed_count()/dc6_enable if power_domains->dc_state
says that DC6 was indeed enabled by the driver (instead of checking the
HW state).
That would fix the reporter's oops when calling
intel_dmc_update_dc6_allowed_count(start_tracking=false), by not calling
it if the driver hasn't actually enabled DC6 and it would also keep the
DC6 counter tracking correct.
intel_dmc_update_dc6_allowed_count(start_tracking=true) would be also
guaranteed to be called only once the firmware is loaded, as until that
point enabling DC6 is blocked (by holding a reference on the DC_off
power well).
> ---
> drivers/gpu/drm/i915/display/intel_dmc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 2fb6fec6dc99..169bbbc91f6d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -1570,10 +1570,10 @@ void intel_dmc_update_dc6_allowed_count(struct intel_display *display,
> struct intel_dmc *dmc = display_to_dmc(display);
> u32 dc5_cur_count;
>
> - if (DISPLAY_VER(dmc->display) < 14)
> + if (!dmc || DISPLAY_VER(display) < 14)
> return;
>
> - dc5_cur_count = intel_de_read(dmc->display, DG1_DMC_DEBUG_DC5_COUNT);
> + dc5_cur_count = intel_de_read(display, DG1_DMC_DEBUG_DC5_COUNT);
>
> if (!start_tracking)
> dmc->dc6_allowed.count += dc5_cur_count - dmc->dc6_allowed.dc5_start;
> @@ -1587,7 +1587,7 @@ static bool intel_dmc_get_dc6_allowed_count(struct intel_display *display, u32 *
> struct intel_dmc *dmc = display_to_dmc(display);
> bool dc6_enabled;
>
> - if (DISPLAY_VER(display) < 14)
> + if (!dmc || DISPLAY_VER(display) < 14)
> return false;
>
> mutex_lock(&power_domains->lock);
> --
> 2.47.3
>
next prev parent reply other threads:[~2025-12-02 21:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-02 18:39 [PATCH] drm/i915/dmc: fix an unlikely NULL pointer deference at probe Jani Nikula
2025-12-02 21:24 ` Imre Deak [this message]
2025-12-02 21:35 ` Imre Deak
2025-12-03 8:13 ` Jani Nikula
2025-12-03 10:38 ` Imre Deak
2025-12-04 11:30 ` Jani Nikula
2025-12-04 13:02 ` Imre Deak
2026-01-07 11:16 ` Jani Nikula
2026-03-02 17:48 ` [PATCH v2] " Imre Deak
2026-03-03 2:44 ` Tao Liu
2026-03-06 10:12 ` Jani Nikula
2026-03-06 14:57 ` Imre Deak
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=aS9ZGmXG_n0IXv-N@ideak-desk \
--to=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=mohammed.thasleem@intel.com \
--cc=stable@vger.kernel.org \
/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