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

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

[gregkh]

This is a note to let you know that I've just added the patch titled

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

to the 6.18-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     drm-dp-read-the-pcon-max-frl-bandwidth-only-for-hdmi-dfps.patch
and it can be found in the queue-6.18 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


From e40e20ac089e32f1d910636155dc82e61e61dcf3 Mon Sep 17 00:00:00 2001
From: Alexander Kaplan <alexander.kaplan@sms-medipool.de>
Date: Wed, 10 Jun 2026 21:38:25 +0200
Subject: drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs

From: Alexander Kaplan <alexander.kaplan@sms-medipool.de>

commit e40e20ac089e32f1d910636155dc82e61e61dcf3 upstream.

The PCON max FRL bandwidth field lives in byte 2 of the DFP Detailed
Capability Info (DPCD 0x82 for the first DFP).
The DP standard defines the meaning of descriptor bytes 1-3 strictly
per DFP type, and for a DisplayPort type DFP all of them are
reserved, with "read all 0s" semantics (DP v2.0, section 2.12.3,
Table 2-183).
The FRL bandwidth field is an HDMI DFP extension added by the VESA
DP-to-HDMI PCON specification.
drm_dp_get_pcon_max_frl_bw() however parses the byte without checking
the DFP type, the branch presence or DETAILED_CAP_INFO_AVAILABLE.
Without the latter the port descriptors are one byte wide and
port_cap[2] is not even the right register.

All neighbouring helpers parsing the same descriptor are scoped by
the DFP type already, see for instance drm_dp_downstream_max_bpc()
reading the same byte and returning 0 for a DP type DFP.
amdgpu's DC parses the field only for HDMI(/DP++) detailed types as
well.

This is not theoretical.
A Synaptics VMM7100 based USB-C to HDMI adapter with a macOS targeted
firmware advertises a DisplayPort type DFP with the type byte
replicated across the whole descriptor (08 08 08 08).
i915 decodes that as "PCON limited to 18 Gbps FRL" and prunes every
mode above ~750 MHz dotclock, including all the 4k@100/120 modes the
sink EDID offers, while macOS drives 4k@120 through the same adapter
just fine via DP DSC (and amdgpu's type-scoped parser would ignore
the bogus field as well).

Only parse the field for an HDMI DFP behind a DPCD 1.1+ branch
device that reports detailed cap info, matching the type-scoped
field layout of the spec and the rest of the helpers.

Fixes: ce32a6239de6 ("drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com> (v2)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.12+
Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260610193825.2933-1-alexander.kaplan@sms-medipool.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/gpu/drm/display/drm_dp_helper.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

--- 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
 	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;
+
 	buf = port_cap[2];
 	bw = buf & DP_PCON_MAX_FRL_BW;
 


Patches currently in stable-queue which might be from alexander.kaplan@sms-medipool.de are

queue-6.18/drm-i915-dp-ignore-the-sink-s-dsc-max-frl-rate-witho.patch
queue-6.18/drm-dp-read-the-pcon-max-frl-bandwidth-only-for-hdmi-dfps.patch

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]

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