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
next prev parent 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