Re: Patch "drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs" has been added to the 6.12-stable tree

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

Pre-existing issues:
- [High] Unvalidated access to `intel_dp->downstream_ports[2]` in `intel_dp_check_frl_training` can lead to unintended DPCD writes on non-PCON branch devices.
--

--- Patch [1]: Patch "drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs" has been added to the 6.12-stable tree ---
commit 2ea84f7dc055ccb41f2cbb8400d14ddf081c3a76
Author: [email protected] <[email protected]>
Date:   Wed Aug 5 12:04:51 2026 +0000

drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs

This commit updates drm_dp_get_pcon_max_frl_bw() to verify that the DFP is an
HDMI port and that detailed capability information is available before parsing
the PCON max FRL bandwidth. This prevents misinterpreting DP descriptors as FRL
bandwidth limits, which previously caused valid high-resolution display modes
to be pruned on some adapters.

Link: https://patch.msgid.link/[email protected]

> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c b/drivers/gpu/drm/display/drm_dp_helper.c
> index 6ee51003de3ce..e2fd2a8ac80d3 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -3145,6 +3145,18 @@ int drm_dp_get_pcon_max_frl_bw(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>  	int bw;
>  	u8 buf;
>  
> +	if (!drm_dp_is_branch(dpcd))
> +		return 0;
> +
> +	if (dpcd[DP_DPCD_REV] < 0x11)
> +		return 0;
> +
> +	if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
> +		return 0;
> +
> +	if ((port_cap[0] & DP_DS_PORT_TYPE_MASK) != DP_DS_PORT_TYPE_HDMI)
> +		return 0;
> +

[Severity: High]
This is a pre-existing issue, but can unvalidated access to downstream_ports[2]
lead to unintended DPCD writes on non-PCON branch devices?

Looking at intel_dp_check_frl_training() in
drivers/gpu/drm/i915/display/intel_dp.c, downstream_ports[2] is evaluated
without first ensuring DP_DETAILED_CAP_INFO_AVAILABLE is set and the port is
an HDMI PCON:

drivers/gpu/drm/i915/display/intel_dp.c:intel_dp_check_frl_training() {
    ...
	if (!(intel_dp->downstream_ports[2] & DP_PCON_SOURCE_CTL_MODE) ||
	    !intel_dp_is_hdmi_2_1_sink(intel_dp) ||
    ...
}

If a non-PCON multi-port branch device (e.g., a dock) without detailed
capability info has an Analog (Type 1) or 'Other' (Type 3) port as its third
downstream port, its short capability byte at downstream_ports[2] will have
bit 0 set.

This incorrectly satisfies the DP_PCON_SOURCE_CTL_MODE check. If an HDMI 2.1
display is connected, intel_dp_is_hdmi_2_1_sink() returns true. FRL training
will fail, causing the driver to blindly execute a TMDS fallback and write to
DPCD register 0x305A (DP_PCON_HDMI_LINK_CONFIG_1):

drivers/gpu/drm/i915/display/intel_dp.c:intel_dp_pcon_set_tmds_mode() {
    ...
	ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
    ...
}

Should the i915 driver also verify DETAILED_CAP_INFO_AVAILABLE and
DP_DS_PORT_TYPE_HDMI before evaluating downstream_ports[2] in this code path?

>  	buf = port_cap[2];
>  	bw = buf & DP_PCON_MAX_FRL_BW;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/2026080551-trimming-acting-66fa@gregkh?part=1