linux-kernel - Re: [PATCH] [RFC] thunderbolt: Add delay for Dell U2725QE link width

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: <5d7f2661-f02b-4985-b438-196b48c10237@amd.com>
Date: Wed, 17 Dec 2025 09:53:06 -0600
From: Mario Limonciello <mario.limonciello@....com>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>,
 AceLan Kao <acelan.kao@...onical.com>
Cc: Andreas Noever <andreas.noever@...il.com>,
 Mika Westerberg <westeri@...nel.org>, Yehezkel Bernat
 <YehezkelShB@...il.com>, linux-usb@...r.kernel.org,
 linux-kernel@...r.kernel.org, Sanath.S@....com,
 "Lin, Wayne" <Wayne.Lin@....com>
Subject: Re: [PATCH] [RFC] thunderbolt: Add delay for Dell U2725QE link width

On 12/17/25 6:55 AM, Mika Westerberg wrote:
> Hi,
> 
> On Wed, Dec 17, 2025 at 11:06:52AM +0800, AceLan Kao wrote:
>>>> By default it does not access retimers beyond the Type-C connector. I
>>>> wonder if you have CONFIG_USB4_DEBUGFS_MARGINING set in your kernel
>>>> .config? And if yes can you disable that and try again.
>> Sorry, it looks like I got some troubles with my MTA, some emails are
>> not sent out correctly.
>>
>> I've rebuilt the kernel without CONFIG_USB4_DEBUGFS_MARGINING, and
>> here is the log
>> There is a tbt storage daisy-chained after the tbt monitor, it's
>> easier to reproduce this issue.
>> https://people.canonical.com/~acelan/bugs/tbt_call_trace/intel/merged_6.18.0-d358e5254674+.2.out
>>
>> And this one is only the tbt monitor plugged.
>> https://people.canonical.com/~acelan/bugs/tbt_call_trace/intel/merged_6.18.0-d358e5254674+.3.out
> 
> Okay from the first trace at least scanning of the retimer at index 2
> (which does not exist) does not complete too fast and I suspect there is
> some timeout on the device side that triggers. We had already similar with
> Pluggable devices but perhaps this is implemented in the Dell version too?
> 
> I wonder it is enough if we set configuration valid and then scan the
> downstream retimers? Can you try the attached patch? We do need to scan
> them before DP tunnels are created to support ALPM (this is work in
> progress).

If it needs to go even later - there is OFC the possibility of doing 
upstream ones first and USB3 tunnels first too.

I'd say if the below doesn't work Acelan you can try pushing it right 
before tp_add_dp_resources() to see.

> 
> diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
> index d7f32a63fc1e..e23e0ee9c95f 100644
> --- a/drivers/thunderbolt/tb.c
> +++ b/drivers/thunderbolt/tb.c
> @@ -1380,14 +1380,6 @@ static void tb_scan_port(struct tb_port *port)
>   	upstream_port = tb_upstream_port(sw);
>   	tb_configure_link(port, upstream_port, sw);
>   
> -	/*
> -	 * Scan for downstream retimers. We only scan them after the
> -	 * router has been enumerated to avoid issues with certain
> -	 * Pluggable devices that expect the host to enumerate them
> -	 * within certain timeout.
> -	 */
> -	tb_retimer_scan(port, true);
> -
>   	/*
>   	 * CL0s and CL1 are enabled and supported together.
>   	 * Silently ignore CLx enabling in case CLx is not supported.
> @@ -1406,6 +1398,13 @@ static void tb_scan_port(struct tb_port *port)
>   	 */
>   	tb_switch_configuration_valid(sw);
>   
> +	/*
> +	 * Scan for downstream retimers. We only scan them after the
> +	 * router has been enumerated to avoid issues with certain
> +	 * Pluggable devices that expect the host to enumerate them
> +	 * within certain timeout.
> +	 */
> +	tb_retimer_scan(port, true);

Just a note in case this turns into a proper patch/solution.  Make sure 
you update the comment to cover this monitor too.

>   	/* Scan upstream retimers */
>   	tb_retimer_scan(upstream_port, true);
>