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] [thread-next>] [day] [month] [year] [list]

Message-ID: <7u6z5gp5ma2jg5zzxniupu4zuipjgxgnjydltx5cntikjtf3ww@qb62nuy7jsfk>
Date: Wed, 31 Dec 2025 09:33:15 +0800
From: "Chia-Lin Kao (AceLan)" <acelan.kao@...onical.com>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: Mario Limonciello <mario.limonciello@....com>, 
	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 Tue, Dec 30, 2025 at 08:30:11AM +0100, Mika Westerberg wrote:
> On Mon, Dec 22, 2025 at 09:33:48AM +0800, Chia-Lin Kao (AceLan) wrote:
> > On Thu, Dec 18, 2025 at 11:20:21AM +0100, Mika Westerberg wrote:
> > > On Thu, Dec 18, 2025 at 03:35:05PM +0800, Chia-Lin Kao (AceLan) wrote:
> > > > > Now since USB 2.x has its own wires in Type-C cable this tells me that
> > > > > there is some real problem with the connection. Have you tried different
> > > > > cables already?
> > > > Here is the log I got with another tbt4 cable.
> > > > I'm using the kernel with Mario suggests modification.
> > > >
> > > > https://people.canonical.com/~acelan/bugs/tbt_call_trace/intel/merged_6.18.0-d358e5254674+.patched2.2_new_cable.out
> > >
> > > Here I see (assuming I read it right) that the USB 2.x enumerates only
> > > after the first unplug:
> > >
> > > [   28.589861] usb 3-2: New USB device found, idVendor=1d5c, idProduct=5801, bcdDevice= 1.01
> > > [   28.589864] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> > > [   28.589865] usb 3-2: Product: USB2.0 Hub
> > > [   28.589866] usb 3-2: Manufacturer: Fresco Logic, Inc.
> > >From the logs, sometimes this hub is enumerated before the call trace
> > and then enumerated again after the call trace.
> >
> > And I also found there are some suspicious USB disconnections while
> > plugging in the tbt monitor.
> >
> > I tried to avoid the USB disconnection by the following modification,
> > but still no luck.
>
> Okay but I think this is not a SW issue, rather an issue with that
> particular monitor/cable/connection/PD. It is not just the USB4 link that
> goes down it's the whole type-C connection therefore something is wrong on
> the electrical side of things (well at least it seems so).
If that's the case, would you agree to suppress the scary call trace
like this?

diff --git a/drivers/thunderbolt/path.c b/drivers/thunderbolt/path.c
index f9b11dadfbdd..ae7127eca542 100644
--- a/drivers/thunderbolt/path.c
+++ b/drivers/thunderbolt/path.c
@@ -586,7 +586,18 @@ int tb_path_activate(struct tb_path *path)
        tb_dbg(path->tb, "%s path activation complete\n", path->name);
        return 0;
 err:
-       tb_WARN(path->tb, "%s path activation failed\n", path->name);
+       /*
+        * -ENOTCONN can occur during transient hardware states like lane
+        * bonding or when the Type-C connection has electrical issues. The
+        * hardware may automatically retry by reconnecting. Use a regular
+        * warning instead of tb_WARN to avoid generating call traces for
+        * these expected transient conditions.
+        */
+       if (res == -ENOTCONN)
+               tb_warn(path->tb, "%s path activation failed (port not connected)\n",
+                       path->name);
+       else
+               tb_WARN(path->tb, "%s path activation failed\n", path->name);
        return res;
 }

>
> Dell also typically validate that their stuff works in Linux so I would
> expect to got some report from them if that's not the case (unless you are
> doing just that ;-))
Currently, the issue could be reproduced on the AMD platform every
time when plugging in the tbt monitor. We don't report the issue on
Intel platform yet, because of it's low failrate.
And the issue is not critical, as it can be recovered after
re-enumerating the monitor.
So maybe they won't bother you about this issue.

>
> Have you tried this same monitor with Windows? Do you see the same issue
> there? I would expect so.