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

[Chia-Lin Kao (AceLan)]

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.

```
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index be50d03034a9..ed3756065568 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -5697,6 +5697,22 @@ static void hub_port_connect_change(struct usb_hub *hub, int port1,
                        /* Don't resuscitate */;
                }
        }
+#ifdef CONFIG_PM
+       /* Handle device with temporarily lost connection */
+       else if (!(portstatus & USB_PORT_STAT_CONNECTION) && udev &&
+                       udev->state != USB_STATE_NOTATTACHED &&
+                       udev->persist_enabled) {
+               /*
+                * If a device with persist enabled temporarily loses connection
+                * during parent hub reconfiguration (e.g., Thunderbolt re-probe),
+                * don't immediately disconnect it. Clear the change bit and
+                * let the hub resume process handle it properly.
+                */
+               dev_dbg(&port_dev->dev, "device (state=%d) lost connection temporarily, not disconnecting\n",
+                               udev->state);
+               status = 0;
+       }
+#endif
        clear_bit(port1, hub->change_bits);

        /* successfully revalidated the connection */
```

Here is the log with the modification.
https://people.canonical.com/~acelan/bugs/tbt_call_trace/intel/merged_6.18.0-d358e5254674+.usb_temporarily_lost_connection.out

> 
> Since Goshen Ridge is pretty stable in Linux I'm kind of suspecting still a
> connection issue rather than SW. Or could be power related too. AFAIK the
> USB 2.x should be rock solid but here it seems not. Are you using active or
> passive cables and do they have the lightning logo?
I can't tell the cable is active or passive, there is a lightning logo
on the both sides of the cable, and also a number "4" on the both sides.

> 
> You could still try to comment out both tb_retimer_scan() calls and see if
> that makes any difference but I doubt since your last log unplug happened
> when we were reading DROM of the second device router not when sidband
> access was done.
I still think it's waiting for something ready, but I don't know what it's
waiting for. Here is the log after applied the 2 seconds sleep.

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

On AMD system, the issue could be reproduced 100% and requires at least
2 seconds to avoid the call trace.
I guess on Intel system the value could be lower, because the
reproduce rate is around 10% ~ 20% on Intel system.