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

[sashiko-bot@kernel.org]

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

New issues:
- [Medium] Omission of DP++ (DP Dual Mode) support when checking HDMI DFP types.

Pre-existing issues:
- [High] Missing DPCD capabilities and DFP type check in `intel_dp_check_frl_training()`.
--

--- Patch [1]: Patch "drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs" has been added to the 6.18-stable tree ---
commit 580edf550253578c69a6a51eb6abfe83d33b3d72
Author: gregkh@linuxfoundation.org <gregkh@linuxfoundation.org>

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

This commit restricts drm_dp_get_pcon_max_frl_bw() to only parse the FRL
bandwidth field for an HDMI DFP behind a DPCD 1.1+ branch device that reports
detailed capability info. Previously, it parsed the byte without checking the
DFP type, leading to incorrect parsing on some adapters.

Link: https://patch.msgid.link/20260610193825.2933-1-alexander.kaplan@sms-medipool.de

> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c b/drivers/gpu/drm/display/drm_dp_helper.c
> index 4aaeae4fa03c3..8c858ba40c6c6 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -3457,6 +3457,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: Medium]
Does this strict check for DP_DS_PORT_TYPE_HDMI inadvertently omit DP++
(DP Dual Mode) support?

As mentioned in the commit message, amdgpu's DC parses the field for both HDMI
and DP++ detailed types. Other helpers like drm_dp_downstream_max_bpc() also
handle DP++ alongside HDMI. By rejecting DP_DS_PORT_TYPE_DP_DUALMODE, could
active DP-to-HDMI adapters identifying as DP++ have their max FRL bandwidth
evaluated as 0 Gbps, leading to a loss of FRL capabilities?

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

[Severity: High]
This is a pre-existing issue, but is it possible for
intel_dp_check_frl_training() to incorrectly write to PCON DPCD registers on a
non-PCON branch device?

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) ||
	    intel_dp->frl.is_trained)
		return;

	if (intel_dp_pcon_start_frl_training(intel_dp) < 0) {
    ...
}

The function checks intel_dp->downstream_ports[2] & DP_PCON_SOURCE_CTL_MODE
without first verifying DP_DETAILED_CAP_INFO_AVAILABLE or that the port is an
HDMI DFP. If a branch device without detailed caps has 3 or more ports,
downstream_ports[2] could contain the capability byte of the 3rd port.

If this port is of type NON_EDID, bits 4-7 contain the NON_EDID mask, which
could naturally have bit 5 set. This could lead the driver to assume the branch
is a PCON and erroneously write to PCON-specific DPCD registers.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/2026080539-uncross-canopener-192f@gregkh?part=1