linux-kernel - Re: [PATCH v2] drm/dp: Add byte-by-byte fallback for broken USB-C adapters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <685f4a41-b90c-4f8f-b4be-531eae1905ce@kernel.org>
Date: Fri, 9 Jan 2026 11:32:05 -0600
From: Mario Limonciello <superm1@...nel.org>
To: "Chia-Lin Kao (AceLan)" <acelan.kao@...onical.com>
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] drm/dp: Add byte-by-byte fallback for broken USB-C
 adapters

On 12/3/25 8:46 PM, Chia-Lin Kao (AceLan) wrote:
> Some USB-C hubs and adapters have buggy firmware where multi-byte AUX
> reads consistently timeout, while single-byte reads from the same address
> work correctly.
> 
> Known affected devices that exhibit this issue:
> - Lenovo USB-C to VGA adapter (VIA VL817 chipset)
>    idVendor=17ef, idProduct=7217
> - Dell DA310 USB-C mobile adapter hub
>    idVendor=413c, idProduct=c010
> 
> Analysis of the failure pattern shows:
> - Single-byte probes to 0xf0000 (LTTPR) succeed
> - Single-byte probes to 0x00102 (TRAINING_AUX_RD_INTERVAL) succeed
> - Multi-byte reads from 0x00000 (DPCD capabilities) timeout with -ETIMEDOUT
> - Retrying does not help - the failure is consistent across all attempts
> 
> The issue appears to be a firmware bug in the AUX transaction handling
> that specifically affects multi-byte reads.
> 
> Add a fallback mechanism in drm_dp_dpcd_read_data() that attempts
> byte-by-byte reading when the normal multi-byte read fails. This
> workaround only activates for adapters that fail the standard read path,
> ensuring no impact on correctly functioning hardware.
> 
> Tested with:
> - Lenovo USB-C to VGA adapter (VIA VL817) - now works with fallback
> - Dell DA310 USB-C hub - now works with fallback
> - Dell/Analogix Slimport adapter - continues to work with normal path
> 
> Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@...onical.com>

Reviewed-by: Mario Limonciello (AMD) <superm1@...nel.org>

As this fixes reads for some existing hardware on the market and is just 
in fallback path I feel this is low risk.  I've applied this to 
drm-misc-fixes.

a8f49a0043011 (HEAD -> drm-misc-fixes) drm/dp: Add byte-by-byte fallback 
for broken USB-C adapters

> ---
> v2. 1. Move the workaround from intel_dp_read_dprx_caps() to
>         drm_dp_dpcd_read_data(), so that it applies to all DPCD reads across
>         all DRM drivers benefit from this fix, not just i915.
>      2. Move the definition of drm_dp_dpcd_readb() before
>         drm_dp_dpcd_read_data()
> ---
>   include/drm/display/drm_dp_helper.h | 57 +++++++++++++++++++----------
>   1 file changed, 37 insertions(+), 20 deletions(-)
> 
> diff --git a/include/drm/display/drm_dp_helper.h b/include/drm/display/drm_dp_helper.h
> index df2f24b950e4..14d2859f0bda 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -551,6 +551,22 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
>   ssize_t drm_dp_dpcd_write(struct drm_dp_aux *aux, unsigned int offset,
>   			  void *buffer, size_t size);
>   
> +/**
> + * drm_dp_dpcd_readb() - read a single byte from the DPCD
> + * @aux: DisplayPort AUX channel
> + * @offset: address of the register to read
> + * @valuep: location where the value of the register will be stored
> + *
> + * Returns the number of bytes transferred (1) on success, or a negative
> + * error code on failure. In most of the cases you should be using
> + * drm_dp_dpcd_read_byte() instead.
> + */
> +static inline ssize_t drm_dp_dpcd_readb(struct drm_dp_aux *aux,
> +					unsigned int offset, u8 *valuep)
> +{
> +	return drm_dp_dpcd_read(aux, offset, valuep, 1);
> +}
> +
>   /**
>    * drm_dp_dpcd_read_data() - read a series of bytes from the DPCD
>    * @aux: DisplayPort AUX channel (SST or MST)
> @@ -570,12 +586,29 @@ static inline int drm_dp_dpcd_read_data(struct drm_dp_aux *aux,
>   					void *buffer, size_t size)
>   {
>   	int ret;
> +	size_t i;
> +	u8 *buf = buffer;
>   
>   	ret = drm_dp_dpcd_read(aux, offset, buffer, size);
> -	if (ret < 0)
> -		return ret;
> -	if (ret < size)
> -		return -EPROTO;
> +	if (ret >= 0) {
> +		if (ret < size)
> +			return -EPROTO;
> +		return 0;
> +	}
> +
> +	/*
> +	 * Workaround for USB-C hubs/adapters with buggy firmware that fail
> +	 * multi-byte AUX reads but work with single-byte reads.
> +	 * Known affected devices:
> +	 * - Lenovo USB-C to VGA adapter (VIA VL817, idVendor=17ef, idProduct=7217)
> +	 * - Dell DA310 USB-C hub (idVendor=413c, idProduct=c010)
> +	 * Attempt byte-by-byte reading as a fallback.
> +	 */
> +	for (i = 0; i < size; i++) {
> +		ret = drm_dp_dpcd_readb(aux, offset + i, &buf[i]);
> +		if (ret < 0)
> +			return ret;
> +	}
>   
>   	return 0;
>   }
> @@ -609,22 +642,6 @@ static inline int drm_dp_dpcd_write_data(struct drm_dp_aux *aux,
>   	return 0;
>   }
>   
> -/**
> - * drm_dp_dpcd_readb() - read a single byte from the DPCD
> - * @aux: DisplayPort AUX channel
> - * @offset: address of the register to read
> - * @valuep: location where the value of the register will be stored
> - *
> - * Returns the number of bytes transferred (1) on success, or a negative
> - * error code on failure. In most of the cases you should be using
> - * drm_dp_dpcd_read_byte() instead.
> - */
> -static inline ssize_t drm_dp_dpcd_readb(struct drm_dp_aux *aux,
> -					unsigned int offset, u8 *valuep)
> -{
> -	return drm_dp_dpcd_read(aux, offset, valuep, 1);
> -}
> -
>   /**
>    * drm_dp_dpcd_writeb() - write a single byte to the DPCD
>    * @aux: DisplayPort AUX channel