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: <20251231060333.GK2275908@black.igk.intel.com>
Date: Wed, 31 Dec 2025 07:03:33 +0100
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: "Chia-Lin Kao (AceLan)" <acelan.kao@...onical.com>,
	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 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().

> > 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.