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: <xgreoxrfzdgeupv4q7ge7ivjwz7dll7khohm4wetjjm3waztwo@lrr2kjdjpdba>
Date: Fri, 2 Jan 2026 10:03:12 +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 Wed, Dec 31, 2025 at 07:03:33AM +0100, Mika Westerberg wrote:
> On Wed, Dec 31, 2025 at 09:33:15AM +0800, Chia-Lin Kao (AceLan) wrote:
> > 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;
> >  }
>
> Yes please but make it unconditionally do tb_warn() instead of that
> tb_WARN().
Got it.

>
> > > 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.
>
> You only have one of those monitors? It would be good to check with another
> if it has the same issue. I have GR reference device here which is what
> this monitor is based on but I don't see any unplugs or link issues. I will
> ask around if we have somewhere this monitor.
Here is another BenQ 5k thunderbolt 4 monitor, and I can't reproduce
the issue with this monitor, even with the AMD machine.

https://people.canonical.com/~acelan/bugs/tbt_call_trace/intel/merged_6.18.0-d358e5254674+.benq.out