From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D67836F91F for ; Thu, 4 Jun 2026 06:26:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.125.188.123 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780554407; cv=none; b=X9x+8FRryRuFkMAo/nKApYO/HICpwI/whnOdjweRf6v4xqdCY2ptnvGF52dr+AIUHUPDixiLvb2m1+mJiRKh8YIeD0mE129bZFffY/G6vSEoCFLKnW0QrzNWXVpOVg9vctRevd/4SQogQfXNZXlpULd9Wfi1s6t12ds9lBzGZNg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780554407; c=relaxed/simple; bh=0UhDC8LuiOMi3lK4zGAtQ0snKLx46fscCKwtJ6wqq9k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JudUVhLGSeqzQxLAM1GmfGyKzsulSmhfHIM9q1PZ3eXf88RAnYrXUsXZRs20Yjtt0vs/L1DwbQ/1sQHrquHHxq1eQEwPHL842Sg08icQsC5VXOvHwkXsq76M9smtowzv7aisG5iGNqvA1Frl02z2Cp+Nwjmod4qa+KAGC0EdsoA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=canonical.com; spf=pass smtp.mailfrom=canonical.com; dkim=pass (4096-bit key) header.d=canonical.com header.i=@canonical.com header.b=iTKojcA6; arc=none smtp.client-ip=185.125.188.123 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=canonical.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=canonical.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (4096-bit key) header.d=canonical.com header.i=@canonical.com header.b="iTKojcA6" Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 3A08D3F637 for ; Thu, 4 Jun 2026 06:26:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20251003; t=1780554395; bh=vsMHKIFpUIhrPk0DECdef2DbD+vUYw7WHkW/xtElA+0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=iTKojcA6GmXO1gCYaRNq6AlODaOYIG+W65tPUjRleD7iQHYBAWydYgfUtUlvzJjhV SWu4rGDK9uiP0xi6a28I5nZw1+xGi1AR/si7J1GojeiFyimbwEFCEHfW+QHmfS+FAi 6VC7ModqALO56EZIiJz8vGip0WMFo3Ydnba/7fyLpo0rA92kkzjrr5zV+9c9f7fCx7 gl6xKCLMYIAohW/cBJ3e2j3eOWXufJybPkvdwdIeesO1dw8gqJrvi6C3qhnBlJ3++r ZvyQxIoBuSmLLido1V2Eue384RSrdM4TKh1rUq12qlBNmBtUlfJuM1mdjBiKPYkCq1 yreFgV6TJFw8wMIw5cwGs5atyG8q0vEUiFv7rZVrsBmDq453Hgy/QJNp/d6q57Pkr6 RJ4zHQ1Ae/I2+tGt5E5oTPCWUJ66zOc3JLE6Gx9e0n6a/bmwbAeXyudDDAH0jnwmiX wiBaFfDlisBR//pLvl0wQ/4B1UMH6i4HLiM7XHv9EUbqGL/043n0y83yINZK4sdS6V i9MaAJTHFIxf7V3mjg+iCNb1wo70JYaHzLDvPHwU3EHke4Y8bv5tgaGpMjQDElrOvp WQ7T1Ocn7MaQg3ysYoZtoDk18yfxu3JNrKLhJAoY0Cb+TdEVp/ZmeVwlmUprBtuWas GXC1H7VltAoSyKclGjGWjUVI= Received: by mail-pf1-f197.google.com with SMTP id d2e1a72fcca58-842278a630dso523618b3a.2 for ; Wed, 03 Jun 2026 23:26:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780554394; x=1781159194; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vsMHKIFpUIhrPk0DECdef2DbD+vUYw7WHkW/xtElA+0=; b=VRCOv1r2grfmEbMhic7cRT489MMfGoAksTXbnOovvFT18qN6UCEQS6PvhPcFItWihV O18rbfCHbguK6noIav9c6pZLGVRPhme4qW65K/HetJDe/ixsPy5+gj9Z0sSLxkTCL8CE YAfeFUoAf7031ZekvUPByQywgPaZp5AZTZKQgdnfQdNdk4+zL2Aq5RzNCTpbUnS62iAl B0xUysZQmz+uwWuPLBhMepm3gEgzF39vezNVNCu57rO+IHEBMQy0bQhJFEcj4vV38m1m oDdnltt75zK9ty0Q1FXBMbSo8Dy8gRWqXowHp3y29X6nUoLaRZE4+0mMyakDsGAG3QMO N2TQ== X-Forwarded-Encrypted: i=1; AFNElJ9Ozu9W3sUQaHUFPDeU0U1S96clUGWbquyqkQ791V8w0nkFs9Hq57X7FK0bv+amGCFk4Cmk5jngcKn716Y=@vger.kernel.org X-Gm-Message-State: AOJu0YzcDnb6NHxoWSTF7Wz039n3ZSsyPfJiPb9SUwDoahCPU9QNFcbR WQcao5nV+QCXg+ERg2kPJi6KOQR9piY68AfBN/WMENqjByagEVaKr9SNr14DDjC+Yxtij0n7xdp +31ukjQoJQ89pDMNd91Fu069xkq8Q8MgXu9cIjzdDlTUtnzyID++u+wJ80tNWN/JP9wqK2AzyC/ 5XxrHOpw== X-Gm-Gg: Acq92OG4Xbt5BS7xNjpsp0AcRQKlKqYgYN5YVvhBT+zG6Ylafe7xUm78H9f9XrVbLfH ugOrxJHkNTGh6jVYrwC1olx5poMNr4aOY7zWZWijPREfHP0vAxSG7WdboIbuBpb/4IrXdCt9RFr WIGM+2lZzJVyStPF9Kue9t/mTxyXOFK5QoyHVw2Yhu6NBXFdGhu7Iu1CdZLxqcx8R3LB701F6yz PfEk0XkHDiQDFT64FNOSuPhgrs7Ilf9ZxVR/SocFBKdxI5nlra/C6hJKQ4I0r6Ob3ge42Bf2RRr hPpJ++KbVTn6doXsvtdKcVfgcr+jG2OIAPvAp7n07yjbTepLVOh6dDhH5OCnLYj+fhLWphSYYNI JwYKmwiJf8mbD5NOjk4gG+XWHFrx22j29RmaZ1gi/pNIIeMcnsV3pF8En7QsngfXgIUq4V3+q3D bCov+Kv5SYElyZ X-Received: by 2002:a05:6a00:1488:b0:842:6a97:52fb with SMTP id d2e1a72fcca58-84284dc0488mr6562712b3a.18.1780554393640; Wed, 03 Jun 2026 23:26:33 -0700 (PDT) X-Received: by 2002:a05:6a00:1488:b0:842:6a97:52fb with SMTP id d2e1a72fcca58-84284dc0488mr6562689b3a.18.1780554393193; Wed, 03 Jun 2026 23:26:33 -0700 (PDT) Received: from acelan-Precision-5480 (211-75-139-220.hinet-ip.hinet.net. [211.75.139.220]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8428706fa9asm4262986b3a.45.2026.06.03.23.26.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2026 23:26:32 -0700 (PDT) Date: Thu, 4 Jun 2026 14:26:28 +0800 From: "Chia-Lin Kao (AceLan)" To: Jani Nikula Cc: Mario Limonciello , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, ville.syrjala@linux.intel.com Subject: Re: [PATCH v2] drm/dp: Add byte-by-byte fallback for broken USB-C adapters Message-ID: Mail-Followup-To: "Chia-Lin Kao (AceLan)" , Jani Nikula , Mario Limonciello , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, ville.syrjala@linux.intel.com References: <20251204024647.1462866-1-acelan.kao@canonical.com> <685f4a41-b90c-4f8f-b4be-531eae1905ce@kernel.org> <61e9fb8c40b40fc6a1588b29bc2283fdaa313e1d@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61e9fb8c40b40fc6a1588b29bc2283fdaa313e1d@intel.com> On Fri, May 29, 2026 at 04:13:41PM +0300, Jani Nikula wrote: > On Fri, 09 Jan 2026, Mario Limonciello wrote: > > 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) > > > > Reviewed-by: Mario Limonciello (AMD) > > > > 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. > > I've stumbled on this when I was looking at drm_dp_dpcd_read_data(). I > never received the original patch, for whatever reason, even though Lore > says I was Cc'd. This should be my problem that some receivers rejects my email, because I'm using another email account to send the email. I still have issues to send the email via company email account, and hope this email won't be rejected. > > > 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]); > > drm_dp_dpcd_read_byte() should be preferred over drm_dp_dpcd_readb()... > > >> + if (ret < 0) > > ...because drm_dp_dpcd_readb() might return 0 on failures. You need to > use drm_dp_dpcd_readb() == 1 to check for success, which is why > drm_dp_dpcd_read_byte() and drm_dp_dpcd_read_data() were introduced in > the first place. > > Moreover, this ugly workaround only impacts drm_dp_dpcd_read_data() > callers, but there are lots and lots of direct drm_dp_dpcd_read() calls > all over the place, which go unfixed. > > It should be emphasized that DP AUX changes that affect absolutely all > drivers should go through more scrutiny, and require more acks. > > This needs follow-up fixes. I'll do some study and submit the follow-up fixes later. > > > BR, > Jani. > > > >> + 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 > > > > -- > Jani Nikula, Intel