All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Arun R Murthy" <arun.r.murthy@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/pps: don't orphan the VDD wakeref when the HW force bit is reset
Date: Mon, 31 Aug 2026 04:57:29 +0000	[thread overview]
Message-ID: <20260831045729.A64771F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260831044036.1236136-1-arun.r.murthy@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the patch incompletely fixes the wakeref leak by failing to update the VDD off-paths to use the software wakeref as the authoritative record, leaving them vulnerable to the exact same asynchronous hardware state reset.
--

commit 18ac414fc1cf2489e00ff31b05c939f81f2c6a00
Author: Arun R Murthy <arun.r.murthy@intel.com>
drm/i915/pps: don't orphan the VDD wakeref when the HW force bit is reset

This patch attempts to fix a wakeref leak by ensuring the software wakeref
is not overwritten if the volatile hardware bit clears while we still hold
a reference. It updates intel_pps_vdd_on_unlocked to track the wakeref
authoritatively.

Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/8477

> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c b/drivers/gpu/drm/i915/display/intel_pps.c
> index d4c98b150fa2b..43e89aaf419f6 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -758,9 +758,10 @@ bool intel_pps_vdd_on_unlocked(struct intel_dp *intel_dp)
>  	if (edp_have_panel_vdd(intel_dp))
>  		return need_to_disable;

[Severity: High]
This is a pre-existing issue, but does relying on edp_have_panel_vdd()
here leave vdd_wakeref unbalanced if the hardware bit is spuriously set?

If the hardware EDP_FORCE_VDD bit is set asynchronously (e.g., by DMC, DC
states, or BIOS), edp_have_panel_vdd() will return true and bypass
acquiring the wakeref into intel_dp->pps.vdd_wakeref. When the panel is
later turned off, the off-paths might unconditionally drop a reference we
never took.

Additionally, does this fix leave the VDD off-paths vulnerable to the
exact same race with volatile hardware state?

For example, in intel_pps_vdd_off_sync_unlocked():

    if (!edp_have_panel_vdd(intel_dp))
        return;
        
If the hardware bit was reset asynchronously, this early return completely
skips calling intel_display_power_put(), permanently leaking vdd_wakeref.

Similarly, in intel_pps_init_late():

    if (edp_have_panel_vdd(intel_dp))
        edp_panel_vdd_schedule_off(intel_dp);

If the hardware bit cleared, this fails to schedule the delayed wakeref
cleanup, causing another leak.

Should the VDD off-paths also be updated to use vdd_wakeref as the
authoritative record rather than the volatile hardware bit?

> -	drm_WARN_ON(display->drm, intel_dp->pps.vdd_wakeref);
> -	intel_dp->pps.vdd_wakeref = intel_display_power_get(display,
> -							    intel_aux_power_domain(dig_port));
> +	if (!intel_dp->pps.vdd_wakeref)
> +		intel_dp->pps.vdd_wakeref =
> +			intel_display_power_get(display,
> +						intel_aux_power_domain(dig_port));
>  
>  	pp_stat_reg = _pp_stat_reg(intel_dp);
>  	pp_ctrl_reg = _pp_ctrl_reg(intel_dp);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831044036.1236136-1-arun.r.murthy@intel.com?part=1

  reply	other threads:[~2026-08-31  4:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31  4:40 [PATCH] drm/i915/pps: don't orphan the VDD wakeref when the HW force bit is reset Arun R Murthy
2026-08-31  4:57 ` sashiko-bot [this message]
2026-08-31  5:22 ` ✓ i915.CI.BAT: success for " Patchwork
2026-08-31  6:32 ` [PATCH] " Jani Nikula
2026-09-02  8:52   ` Murthy, Arun R
2026-08-31  7:33 ` ✗ i915.CI.Full: failure for " Patchwork
2026-08-31  9:38 ` [PATCHv2] drm/i915/pps: reconcile a BIOS-enabled VDD without leaking its wakeref Arun R Murthy
2026-08-31  9:58   ` sashiko-bot
2026-10-03 20:41   ` [PATCH v3] " Danylo Dobushovkyi
2026-08-31 15:26 ` ✓ i915.CI.BAT: success for drm/i915/pps: don't orphan the VDD wakeref when the HW force bit is reset (rev2) Patchwork
2026-08-31 21:21 ` ✓ i915.CI.Full: " Patchwork
2026-09-21 20:21 ` [PATCH] drm/i915/pps: don't orphan the VDD wakeref when the HW force bit is reset Claude Code (AI assistant, for an i915 user)

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=20260831045729.A64771F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=arun.r.murthy@intel.com \
    --cc=intel-gfx@lists.freedesktop.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 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.