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

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

[Alexander Kaplan]

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 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")
Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de>
---
This patch is part of a set of independent fixes for the USB-C to DP
to HDMI 2.1 protocol converter (PCON) path, found and verified on an
ASUS NUC 16 Pro (Panther Lake, xe) with Synaptics VMM7100 based
adapters.
Each part stands on its own and can be merged independently.
The other parts:
[1] https://lore.kernel.org/r/20260610174413.5881-1-alexander.kaplan@sms-medipool.de
[2] https://lore.kernel.org/r/20260610174807.6231-1-alexander.kaplan@sms-medipool.de
 drivers/gpu/drm/display/drm_dp_helper.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dp_helper.c b/drivers/gpu/drm/display/drm_dp_helper.c
index 9c31e14cc413..3328909c8db4 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -3686,6 +3686,15 @@ 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_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;
 
-- 
2.54.0

Re: [PATCH] drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs

[sashiko-bot]

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

Pre-existing issues:
- [High] `intel_dp_check_frl_training` improperly evaluates source control mode support, potentially initiating FRL training and writing PCON registers on non-PCON or non-HDMI branch devices.
--

commit 4303b79dbb0d5f0f36551e50e709e33e49cee039
Author: Alexander Kaplan <alexander.kaplan@sms-medipool.de>

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

This commit fixes an issue where the PCON max FRL bandwidth was read
without checking the DFP type, branch presence, or whether detailed
capability info was available. By properly scoping the parsing, it
prevents incorrect mode pruning on adapters that replicate the DFP type
byte across the descriptor.

> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c b/drivers/gpu/drm/display/drm_dp_helper.c
> index 9c31e14cc413b..3328909c8db47 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -3686,6 +3686,15 @@ 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_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 seeing the capability checks added
here raises a question about similar logic in the i915 driver.

In drivers/gpu/drm/i915/display/intel_dp.c, the intel_dp_check_frl_training()
function appears to blindly check downstream_ports[2] without verifying
if detailed capabilities are available:

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 detailed capability info is not available, downstream_ports contains 1-byte
descriptors per port. Doesn't this mean downstream_ports[2] would represent
the third downstream port rather than byte 2 of Port 0?

If Port 2 happens to have bit 5 set, could this cause the driver to
incorrectly assume it's a PCON supporting source control mode, triggering
FRL training logic on non-PCON or non-HDMI branch devices? 

Even if the training gracefully aborts due to max_pcon_frl_bw being 0, it
looks like the error path unconditionally calls intel_dp_pcon_set_tmds_mode(),
which writes to DP_PCON_HDMI_LINK_CONFIG_1. Could writing to these registers
on generic MST hubs or docks cause hardware hangs or link training failures?

Should intel_dp_check_frl_training() be updated with similar checks to ensure
we only evaluate DP_PCON_SOURCE_CTL_MODE when appropriate?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260610174819.6258-1-alexander.kaplan@sms-medipool.de?part=1

Re: [PATCH] drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs

[Alexander Kaplan]

On Wed, 10 Jun 2026, sashiko-bot@kernel.org wrote:
> If detailed capability info is not available, downstream_ports contains 1-byte
> descriptors per port. Doesn't this mean downstream_ports[2] would represent
> the third downstream port rather than byte 2 of Port 0?

The DPCD addressing concern is valid.
Without DP_DETAILED_CAP_INFO_AVAILABLE the registers at DPCD 0x80 hold
one byte per port, so downstream_ports[2] is the descriptor of port 2
and not byte 2 of the port 0 descriptor.
Bit 5 can even be legitimately set in that format, where it is part of
the non-EDID format bits (DP_DS_NON_EDID_720x480i_50).
So intel_dp_check_frl_training() evaluating DP_PCON_SOURCE_CTL_MODE on
that byte is indeed unguarded.

The practical exposure is small, though.
The same condition also requires intel_dp_is_hdmi_2_1_sink(), so the
EDID of the attached sink must additionally advertise HDMI FRL rates
in the HF-VSDB.
drm_dp_read_downstream_info() zeroes descriptor bytes beyond the
advertised port count, so hitting the bogus bit takes a branch device
that exposes three or more downstream ports without detailed
capability info while driving an HDMI 2.1 sink, which should be a
rare combination.

> Should intel_dp_check_frl_training() be updated with similar checks to ensure
> we only evaluate DP_PCON_SOURCE_CTL_MODE when appropriate?

This patch also narrows the remaining window.
With it, dfp.pcon_max_frl_bw is only non-zero for a branch device with
detailed capability info and an HDMI downstream port, so in the
scenario above intel_dp_pcon_start_frl_training() now fails the
max_frl_bw check before any FRL DPCD access happens.

What remains is the TMDS fallback write to DP_PCON_HDMI_LINK_CONFIG_1
in the error path of intel_dp_check_frl_training().
Gating the function on intel_dp->dfp.pcon_max_frl_bw, which after this
patch encodes exactly the checks added here, would close that.
That is an i915 change and out of scope for this helper patch.
If the maintainers think it is worth closing, I am happy to send a
separate follow-up patch for that.

Thanks,

Alexander

✗ LGCI.VerificationFailed: failure for drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs

[Patchwork]

== Series Details ==

Series: drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs
URL   : https://patchwork.freedesktop.org/series/168281/
State : failure

== Summary ==

Series author address 'alexander.kaplan@sms-medipool.de' is not on the allowlist, which prevents CI from being automatically triggered.
If you want CI to run for this series, ask Patchwork project owners to click 'retest' on the series in Patchwork.
Exception occurred during validation, bailing out!
Build URL: http://intel-gfx-ci-public.igk.intel.com:8080/job/xe_pw_trigger/1185534/ (on master)

Re: [PATCH] drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs

[Ville Syrjälä]

On Wed, Jun 10, 2026 at 07:48:19PM +0200, Alexander Kaplan wrote:
> 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 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")
> Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de>
> ---
> This patch is part of a set of independent fixes for the USB-C to DP
> to HDMI 2.1 protocol converter (PCON) path, found and verified on an
> ASUS NUC 16 Pro (Panther Lake, xe) with Synaptics VMM7100 based
> adapters.
> Each part stands on its own and can be merged independently.
> The other parts:
> [1] https://lore.kernel.org/r/20260610174413.5881-1-alexander.kaplan@sms-medipool.de
> [2] https://lore.kernel.org/r/20260610174807.6231-1-alexander.kaplan@sms-medipool.de
>  drivers/gpu/drm/display/drm_dp_helper.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c b/drivers/gpu/drm/display/drm_dp_helper.c
> index 9c31e14cc413..3328909c8db4 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -3686,6 +3686,15 @@ 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;
> +

I'd also add a DPCD_REV check because none of this stuff exists for
DPCD v1.0. Granted, the DP_DETAILED_CAP_INFO_AVAILABLE bit should be
zero there (assuming any DPCD v1.0 devices even exists), but I'd
rather have the explicit check anyway so I don't have to think so
much when reading the code.

> +	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;
>  
> -- 
> 2.54.0
> 

-- 
Ville Syrjälä
Intel