From: sashiko-bot@kernel.org
To: "Michał Grzelak" <michal.grzelak@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v11 7/8] drm/i915: override Combo's VS/PE when requested
Date: Thu, 13 Aug 2026 16:50:16 +0000 [thread overview]
Message-ID: <20260813165017.4B5141F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260813160918.918857-8-michal.grzelak@intel.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] EHL PHY override logic incorrectly applies 'low_vswing' settings to non-low_vswing eDP panels
- [Medium] Potential out-of-bounds read during VBT 'tables' parsing
- [Medium] JSL PHY override logic is reversed for HBR2 vs lower port clocks compared to intended behavior
- [Medium] Memory allocated for `devdata->entries` is leaked on early return in vspeo retrieval functions
--
--- Patch [7]: [PATCH v11 7/8] drm/i915: override Combo's VS/PE when requested ---
commit 3f316b5929dec8d0ea8bb76e4cb8983db3b9bf70
Author: Michał Grzelak <michal.grzelak@intel.com>
drm/i915: override Combo's VS/PE when requested
This commit adds accessor functions for the Combo PHY to read requested
VS/PE tables from the VBT. It parses the requested table and transforms
the data to override the port's buffer settings based on platform (EHL/JSL)
and port capabilities.
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
[ ... ]
> +const struct intel_ddi_buf_trans *
> +intel_bios_get_ehl_combo_vspeo(const struct intel_bios_encoder_data *devdata,
> + bool has_dp, int port_clock, bool has_edp)
> +{
[ ... ]
> + if (!validate_vspeo(devdata, has_dp))
> + return NULL;
[Severity: Medium]
Does this early return (and the similar one in intel_bios_get_jsl_combo_vspeo)
cause a memory leak of the devdata->entries buffer?
During teardown in intel_bios_driver_remove(), the driver attempts to free
this memory using kfree(devdata->vspeo->entries). Since vspeo->entries is
assigned much later in this function, returning NULL here leaves
devdata->vspeo->entries uninitialized or NULL. This would cause the teardown
code to skip freeing the memory allocated to devdata->entries.
> +
> + if (has_edp)
> + idx = port_clock > 540000 ? 2 : 1;
> + else
> + idx = port_clock > 270000 ? 1 : 0;
[Severity: High]
The commit message indicates that for EHL, eDP configurations using low
vswing should behave differently from eDP configurations not using low
vswing. However, does this logic unconditionally apply the same table index
logic to all eDP configurations?
It seems intel_bios_get_ehl_combo_vspeo() does not receive or check a
low_vswing parameter (like the JSL equivalent does), applying the same
fallback logic to all eDP panels.
> +
> + offset += idx * num_rows * num_columns;
> +
> + for (level = 0; level < num_rows; level++) {
> + u32 dw2_swing_sel = tables[offset];
> + u32 dw7_n_scalar = tables[offset + 1];
> + u32 dw4_cursor_coeff = tables[offset + 2];
> + u32 dw4_post_cursor_2 = tables[offset + 3];
> + u32 dw4_post_cursor_1 = tables[offset + 4];
[Severity: Medium]
Can this loop read out of bounds if the VBT is malformed?
The parsing calculation offset = idx * num_rows * num_columns followed by
direct accesses up to tables[offset + 4] doesn't appear to validate that
num_columns is at least 5, or that the overall VBT tables buffer is
sized adequately to support the calculated offset and rows.
[ ... ]
> +const struct intel_ddi_buf_trans *
> +intel_bios_get_jsl_combo_vspeo(const struct intel_bios_encoder_data *devdata,
> + bool has_dp, int port_clock, bool low_vswing_edp)
> +{
[ ... ]
> + if (low_vswing_edp) {
> + if (port_clock > 540000)
> + idx = 0;
> + else if (port_clock > 270000)
> + idx = 1;
> + else
> + idx = 2;
> + }
[Severity: Medium]
Is this table selection logic reversed compared to the commit message?
The commit message states: "When encoder supports HBR2 choose 3rd table.
When encoder supports modes lower than HBR2 choose 2nd table."
However, the code assigns idx = 1 (2nd table) for port_clock > 270000 (HBR2)
and idx = 2 (3rd table) for lower modes.
[ ... ]
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
[ ... ]
> +static const struct intel_ddi_buf_trans *
> +ehl_get_combo_buf_trans_override(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state,
> + int *n_entries)
> +{
> + const struct intel_bios_encoder_data *devdata = encoder->devdata;
> + bool has_edp, has_dp;
> + int port_clock;
> +
> + has_edp = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP);
> + has_dp = intel_crtc_has_dp_encoder(crtc_state);
> + port_clock = crtc_state->port_clock;
> +
> + return intel_bios_get_ehl_combo_vspeo(devdata, has_dp, port_clock, has_edp);
> +}
[Severity: High]
Should this override function be checking use_edp_low_vswing(encoder)
similar to how it is checked in jsl_get_combo_buf_trans_override()?
The current implementation omits the low_vswing context entirely, passing
only has_edp down to intel_bios_get_ehl_combo_vspeo(), which prevents the
distinction between low vswing and normal eDP configurations from being made.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813160918.918857-1-michal.grzelak@intel.com?part=7
next prev parent reply other threads:[~2026-08-13 16:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 16:09 [PATCH v11 0/8] Vswing / Pre-emphasis Override Michał Grzelak
2026-08-13 16:09 ` [PATCH v11 1/8] drm/i915/bios: search for VBT #57 by default Michał Grzelak
2026-08-13 16:09 ` [PATCH v11 2/8] drm/i915/bios: store VBT #57's metadata in intel_vbt_data Michał Grzelak
2026-08-13 16:20 ` sashiko-bot
2026-08-13 16:09 ` [PATCH v11 3/8] drm/i915/bios: print VS/PE-O port info Michał Grzelak
2026-08-13 16:09 ` [PATCH v11 4/8] drm/i915/bios: de/allocate VS/PE-O buffers for each port Michał Grzelak
2026-08-13 16:17 ` sashiko-bot
2026-08-13 16:09 ` [PATCH v11 5/8] drm/i915/buf_trans: add vfunc for VS/PE-O Michał Grzelak
2026-08-13 16:09 ` [PATCH v11 6/8] drm/i915: override Snps's VS/PE when requested Michał Grzelak
2026-08-13 16:29 ` sashiko-bot
2026-08-13 16:09 ` [PATCH v11 7/8] drm/i915: override Combo's " Michał Grzelak
2026-08-13 16:50 ` sashiko-bot [this message]
2026-08-13 16:09 ` [PATCH v11 8/8] drm/i915/bios: remove VS/PE-O warning Michał Grzelak
2026-08-13 16:18 ` ✗ CI.checkpatch: warning for Vswing / Pre-emphasis Override (rev6) Patchwork
2026-08-13 16:20 ` ✓ CI.KUnit: success " Patchwork
2026-08-13 17:19 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-13 19:16 ` ✓ 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=20260813165017.4B5141F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=michal.grzelak@intel.com \
--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