Re: [PATCH 4/4] thunderbolt: prevent pcie tunnel activation/teardown warnings

["mika.westerberg@linux.intel.com" <mika.westerberg@linux.intel.com>]

Hi,

On Wed, Nov 04, 2026 at 07:09:50AM +0000, Chunfeng Yun (云春峰) wrote:
> On Tue, 2026-11-03 at 13:48 +0100, mika.westerberg@linux.intel.com
> wrote:
> > Hi,
> > 
> > On Tue, Nov 03, 2026 at 08:33:51AM +0000, Chunfeng Yun (云春峰) wrote:
> > > On Fri, 2026-10-30 at 09:56 +0100, Mika Westerberg wrote:
> > > > On Fri, Oct 30, 2026 at 04:25:39PM +0800, Chunfeng Yun wrote:
> > > > > When usb4 enter sleep mode, echo 1 to authorized of sysfile,
> > > > > will wakeup usb4 driver, but fail to create pcie tunnel, cause
> > > > > the warning due to a race condition between switch disconnect
> > > > 
> > > > It's router
> > > will modify it.
> > > 
> > > > 
> > > > > during resume and user authorization
> > > [  278.831186] usb4_hi NVDA8100:00: 0:1: is unplugged (state: 7),
> > > retrying...
> > > [  278.943031] usb4_hi NVDA8100:00: 0:1: failed to reach state
> > > TB_PORT_UP. Ignoring port...
> > > [  278.951125] usb4_hi NVDA8100:00: 0:1: lost during suspend,
> > > disconnecting
> > > [  278.957819] usb4_hi NVDA8100:00: 0:4 <-> 1:16 (USB3):
> > > deactivating
> > > [  278.964794] usb4_hi NVDA8100:00: deactivating USB3 Down path
> > > from
> > > 0:4 to 1:16
> > > [  278.972737] usb4_hi NVDA8100:00: deactivating USB3 Up path from
> > > 1:16
> > > to 0:4
> > > [  278.980504] usb4_hi NVDA8100:00: 0: TMU: mode change off -> bi-
> > > directional, HiFi requested
> > > [  278.991265] usb4_hi NVDA8100:00: 0: TMU: mode set to: bi-
> > > directional, HiFi
> > > [  278.999511] usb4_hi NVDA8100:00: 0:1: total credits changed 66 -
> > > > 66
> > > [  279.006408] usb4_hi NVDA8100:00: 1: link width set to symmetric,
> > > dual lanes
> > > [  279.013763] usb4_hi NVDA8100:00: 0:7 <-> 1:9 (PCI): activating
> > > [  279.019587] usb4_hi NVDA8100:00: activating PCIe Down path from
> > > 0:7
> > > to 1:9
> > > [  279.026468] usb4_hi NVDA8100:00: 1:1: Writing hop 1
> > > [  279.031335] usb4_hi NVDA8100:00: 1:1:  In HopID: 8 => Out port:
> > > 9
> > > Out HopID: 8
> > > [  279.038546] usb4_hi NVDA8100:00: 1:1:   Weight: 1 Priority: 3
> > > Credits: 32 Drop: 0 PM: 0
> > > [  279.046536] usb4_hi NVDA8100:00: 1:1:    Counter enabled: 0
> > > Counter
> > > index: 2047
> > > [  279.053834] usb4_hi NVDA8100:00: 1:1:   Flow Control (In/Eg):
> > > 1/0
> > > Shared Buffer (In/Eg): 0/0
> > > [  279.062259] usb4_hi NVDA8100:00: 1:1:   Unknown1: 0x0 Unknown2:
> > > 0x0
> > > Unknown3: 0x0
> > > [  279.069730] ------------[ cut here ]------------
> > > [  279.074335] usb4_hi NVDA8100:00: PCIe Down path activation
> > > failed
> > > [  279.080426] WARNING: CPU: 5 PID: 2433 at
> > > drivers/thunderbolt/path.c:587 tb_path_activate+0x1a4/0x5b0
> > > ...
> > > [  279.220285] Call trace:
> > > [  279.222722]  tb_path_activate+0x1a4/0x5b0 (P)
> > > [  279.227068]  tb_tunnel_activate+0x140/0x498
> > > [  279.231241]  tb_tunnel_pci+0x180/0x490
> > > [  279.234980]  tb_domain_approve_switch+0x74/0xb0
> > > [  279.239500]  authorized_store+0x214/0x270
> > > [  279.243498]  dev_attr_store+0x20/0x70
> > > ...
> > > [  279.288888] ---[ end trace 0000000000000000 ]---
> > > [  279.293497] usb4_hi NVDA8100:00: 0:7 <-> 1:9 (PCI): activation
> > > failed
> > > 
> > > 
> > > root cause:
> > > 
> > > The warning were caused by a race condition between switch
> > > disconnect
> > > during resume and user authorization:
> > > 
> > >    1. While the system was in runtime suspend, userspace executed:
> > > 
> > >        echo 1 > /sys/bus/thunderbolt/devices/0-1/authorized
> > >    2. Writing to this sysfs attribute woke up the USB4 controller
> > > (nhi_runtime_resume).
> > >    3. During resume, the downstream port 0:1 failed to complete
> > > link
> > > training within the timeout and was declared lost:
> > 
> > Okay we get the warning but the bigger problem here is that why the
> > link
> > does not come up anymore? 
> Yes, it is one case
> > Unless you unplugged the router as well.
> it is another one.
> 
> if the driver already know the router is disconnected, whether still
> need to look up the pcie tunnel? it want to do it, I will abandon this
> patch.

I think it makes sense to fix it but I was more concerned about the link
issue you seem to have there. The link should be re-trained once we runtime
resume if the router is still connected. There could be many reasons for
this but I would check that the PD/retimer firmwares are up-to-date at
least as they may contribute to this.