Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Animesh Manna" <animesh.manna@intel.com>
Cc: dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v6 12/18] drm/i915/alpm: Program LTTPR count for DP 2.1 ALPM
Date: Tue, 15 Sep 2026 18:56:27 +0000	[thread overview]
Message-ID: <20260915185628.790771F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260915180449.277933-13-animesh.manna@intel.com>

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] drm/i915/alpm: DP 2.1 ALPM LTTPR logic is unreachable dead code
- [Medium] drm/i915/alpm: Unchecked negative return from drm_dp_lttpr_count() causes register corruption
- [Low] drm/i915/alpm: Dead code in lttpr_count error check
- [Low] drm/i915/alpm: Comment contradicts LTTPR revision code check
--

commit a317ca0f7af6803f7b3932311f82447dfda1b648
Author: Animesh Manna <animesh.manna@intel.com>
drm/i915/alpm: Program LTTPR count for DP 2.1 ALPM

This commit programs the total number of LTTPRs for DP 2.1 ALPM before
link training by issuing an AUX write transaction to DP_TOTAL_LTTPR_CNT.

> diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c b/drivers/gpu/drm/i915/display/intel_alpm.c
> index da653a407e97e..06c1a59aa2c51 100644
> --- a/drivers/gpu/drm/i915/display/intel_alpm.c
> +++ b/drivers/gpu/drm/i915/display/intel_alpm.c
> @@ -726,7 +726,7 @@ static void lnl_alpm_configure(struct intel_dp *intel_dp,
>  {
>  	struct intel_display *display = to_intel_display(intel_dp);
>  	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> -	u32 alpm_ctl;
> +	u32 alpm_ctl, alpm_ctl2, lttpr_count;
>  
[ ... ]
> @@ -762,6 +762,11 @@ static void lnl_alpm_configure(struct intel_dp *intel_dp,
>  
>  	alpm_ctl |= ALPM_CTL_ALPM_ENTRY_CHECK(crtc_state->alpm_state.check_entry_lines);
>  
> +	lttpr_count = drm_dp_lttpr_count(intel_dp->lttpr_common_caps);
> +
> +	alpm_ctl2 = ALPM_CTL2_NUMBER_OF_LTTPR(lttpr_count);

[Severity: Medium]
Does this assignment to a u32 variable cause error codes to go unhandled?

The function drm_dp_lttpr_count() can return negative error codes like
-ERANGE or -EINVAL on failure. If this happens, assigning it to the unsigned
lttpr_count variable strips the negative sign and results in a large value
being passed into ALPM_CTL2_NUMBER_OF_LTTPR(). This could corrupt the
register programming by injecting invalid bits via REG_FIELD_PREP.

> +
> +	intel_de_write(display, ALPM_CTL2(display, cpu_transcoder), alpm_ctl2);
>  	intel_de_write(display, ALPM_CTL(display, cpu_transcoder), alpm_ctl);
>  	mutex_unlock(&intel_dp->alpm.lock);
>  }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index cb92cff906146..37c8306a1fa0d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -2265,6 +2265,25 @@ intel_dp_128b132b_link_train(struct intel_dp *intel_dp,
>  	return passed;
>  }
>  
> +static void intel_dp_update_lttpr_count(struct intel_dp *intel_dp,
> +					int lttpr_count)
> +{
> +	u8 val;
> +
> +	/*
> +	 * Program only for DP2.1 and return if LTTPR revison is less than 0x20
> +	 * where 0:3 represents minor rev and 4:7 represent major rev
> +	 */

[Severity: Low]
This isn't a bug, but the comment specifies "less than 0x20", while the
code below implements a less than or equal to 0x20 (<= 0x20) check.

> +	if (!intel_dp_is_edp(intel_dp) ||
> +	    lttpr_count < 0 ||

[Severity: Low]
Is this lttpr_count < 0 check reachable?

In intel_dp_start_link_train(), the lttpr_count is clamped to 0 on error
before being passed to this function:

	if (lttpr_count < 0)
		/* Still continue with enabling the port and link training. */
		lttpr_count = 0;

	intel_dp_prepare_link_train(intel_dp, crtc_state);
	intel_dp_update_lttpr_count(intel_dp, lttpr_count);

> +	    intel_dp->lttpr_common_caps[0] <= 0x20)

[Severity: High]
Can this LTTPR programming ever be reached for either DP or eDP configurations?

For standard DP connections, the function returns immediately because of the
!intel_dp_is_edp(intel_dp) check above.

For eDP connections, intel_dp_init_lttpr_and_dprx_caps() explicitly skips
LTTPR capabilities initialization, leaving intel_dp->lttpr_common_caps[0]
as 0. That causes the function to also return immediately due to this
<= 0x20 check, rendering the feature unreachable.

> +		return;
> +
> +	val = intel_dp->lttpr_common_caps[DP_PHY_REPEATER_CNT -
> +					  DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV];
> +	drm_dp_dpcd_writeb(&intel_dp->aux, DP_TOTAL_LTTPR_CNT, val);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915180449.277933-1-animesh.manna@intel.com?part=12

  reply	other threads:[~2026-09-15 18:56 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15 18:04 [PATCH v6 00/18] Enable DP2.1 alpm Animesh Manna
2026-09-15 18:04 ` [PATCH v6 01/18] drm/i915/alpm: Add DPCD definition for DP2.1 ALPM capability Animesh Manna
2026-09-15 18:04 ` [PATCH v6 02/18] drm/i915/alpm: Move alpm sink capability readout into a separate function Animesh Manna
2026-09-28  9:58   ` Hogander, Jouni
2026-09-28 10:02     ` Hogander, Jouni
2026-09-30  8:04   ` Jani Nikula
2026-10-01 11:21     ` Manna, Animesh
2026-09-15 18:04 ` [PATCH v6 03/18] drm/i915/alpm: alpm_init() for DP2.1 Animesh Manna
2026-09-15 18:57   ` sashiko-bot
2026-09-28 10:44   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 04/18] drm/i915/alpm: Enable debugfs " Animesh Manna
2026-09-28 11:22   ` Hogander, Jouni
2026-10-01 11:32     ` Manna, Animesh
2026-10-08  4:40       ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 05/18] drm/i915/alpm: Refactor Auxless wake time calculation Animesh Manna
2026-09-28 11:49   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 06/18] drm/i915/alpm: Auxless wake time calculation for Xe3p Animesh Manna
2026-09-29  5:34   ` Hogander, Jouni
2026-09-29  5:38   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 07/18] drm/i915/alpm: Modify AUX_LESS_WAKE_TIME bitfield for xe3lpd Animesh Manna
2026-09-15 18:46   ` sashiko-bot
2026-09-29  6:20   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 08/18] drm/i915/alpm: table based establishment period Animesh Manna
2026-09-29  7:00   ` Hogander, Jouni
2026-09-29  7:31     ` Hogander, Jouni
2026-10-01 11:40     ` Manna, Animesh
2026-09-15 18:04 ` [PATCH v6 09/18] drm/i915/alpm: Half LFPS cycle calculation Animesh Manna
2026-09-15 18:53   ` sashiko-bot
2026-09-29  9:57   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 10/18] drm/i915/alpm: Modify LFPS cycle count for DP ALPM Animesh Manna
2026-10-01  6:22   ` Hogander, Jouni
2026-10-01 12:10     ` Hogander, Jouni
2026-10-01 12:11       ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 11/18] drm/i915/alpm: Modify LFPS_CYCLE_COUNT bitfield for xe3lpd Animesh Manna
2026-09-15 18:04 ` [PATCH v6 12/18] drm/i915/alpm: Program LTTPR count for DP 2.1 ALPM Animesh Manna
2026-09-15 18:56   ` sashiko-bot [this message]
2026-09-30  8:16   ` Jani Nikula
2026-10-02  4:41   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 13/18] drm/i915/alpm: Enable MAC Transmitting LFPS for LT PHY Animesh Manna
2026-10-02  5:04   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 14/18] drm/i915/alpm: Replace is_edp() with alpm_is_possible() Animesh Manna
2026-09-15 18:57   ` sashiko-bot
2026-10-02  6:41   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 15/18] drm/i915/alpm: Introduce has_alpm to decouple from pr/psr2/lobf Animesh Manna
2026-09-15 19:01   ` sashiko-bot
2026-10-02  8:37   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 16/18] drm/i915/alpm: Compute and program switch to active latency Animesh Manna
2026-09-15 18:55   ` sashiko-bot
2026-10-02  9:00   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 17/18] drm/i915/alpm: Program zero-based LFPS half cycle duration Animesh Manna
2026-09-15 19:02   ` sashiko-bot
2026-10-02  9:08   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 18/18] drm/i915/alpm: Disallow ALPM for UHBR link rate Animesh Manna
2026-09-15 19:01   ` sashiko-bot
2026-10-02 11:33   ` Hogander, Jouni
2026-09-15 21:11 ` ✓ i915.CI.BAT: success for Enable DP2.1 alpm (rev6) Patchwork
2026-09-16  8:14 ` ✗ i915.CI.Full: failure " 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=20260915185628.790771F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=animesh.manna@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox