tb_find_pcie_down() uses tb_pci_port_is_enabled() to check whether a
mapped downstream PCIe port is already in use before returning it for
tunnel activation. tb_pci_port_is_enabled() returns false both when the
port is genuinely disabled and when tb_port_read() fails (e.g. -EIO).

After resume on TBT5/PTL hardware the host router is not immediately
accessible. A config read on the mapped port returns -EIO. This causes
tb_pci_port_is_enabled() to return false, making tb_find_pcie_down()
treat the still-mapped port as free. tb_tunnel_activate() is then
called on this already-mapped port, fails with -EIO, and logs:

  "PCIe tunnel activation failed, aborting"

The display connected via the Thunderbolt dock is then lost until the
dock is unplugged and replugged.

Fix this by inlining the config read in tb_find_pcie_down() and
distinguishing three outcomes:
  - Read succeeds, PE bit set   -> port in use, skip (goto out)
  - Read succeeds, PE bit clear -> port free, return it
  - Read fails                  -> hardware not ready, skip (goto out)

When hardware is not ready the function falls through to
tb_find_unused_port() which returns NULL, causing tb_tunnel_pci() to
return 0 gracefully. The Connection Manager will retry via the hotplug
event when the device re-announces itself once the link is up.

Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
---
 drivers/thunderbolt/tb.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
index c69c323e6952a..2712927b3837e 100644
--- a/drivers/thunderbolt/tb.c
+++ b/drivers/thunderbolt/tb.c
@@ -1848,9 +1848,26 @@ static struct tb_port *tb_find_pcie_down(struct tb_switch *sw,
 	}
 
 	if (down) {
+		u32 data;
+		int ret;
+
 		if (WARN_ON(!tb_port_is_pcie_down(down)))
 			goto out;
-		if (tb_pci_port_is_enabled(down))
+
+		ret = tb_port_read(down, &data, TB_CFG_PORT,
+				   down->cap_adap + ADP_PCIE_CS_0, 1);
+		if (ret) {
+			/*
+			 * Cannot read the adapter register, this could
+			 * mean the hardware is not ready yet (e.g. after
+			 * resume). Skip this port and fall back to
+			 * finding an unused port to avoid activating a
+			 * tunnel on an already mapped port.
+			 */
+			tb_port_dbg(down, "failed to read PCIe adapter status: %d\n", ret);
+			goto out;
+		}
+		if (data & ADP_PCIE_CS_0_PE)
 			goto out;
 
 		return down;
-- 
2.53.0

Hi,

On Tue, Apr 14, 2026 at 07:37:35PM +0800, Chia-Lin Kao (AceLan) wrote:
> tb_find_pcie_down() uses tb_pci_port_is_enabled() to check whether a
> mapped downstream PCIe port is already in use before returning it for
> tunnel activation. tb_pci_port_is_enabled() returns false both when the
> port is genuinely disabled and when tb_port_read() fails (e.g. -EIO).
> 
> After resume on TBT5/PTL hardware the host router is not immediately
> accessible. A config read on the mapped port returns -EIO. This causes
> tb_pci_port_is_enabled() to return false, making tb_find_pcie_down()
> treat the still-mapped port as free. tb_tunnel_activate() is then
> called on this already-mapped port, fails with -EIO, and logs:
> 
>   "PCIe tunnel activation failed, aborting"
> 
> The display connected via the Thunderbolt dock is then lost until the
> dock is unplugged and replugged.
> 
> Fix this by inlining the config read in tb_find_pcie_down() and
> distinguishing three outcomes:
>   - Read succeeds, PE bit set   -> port in use, skip (goto out)
>   - Read succeeds, PE bit clear -> port free, return it
>   - Read fails                  -> hardware not ready, skip (goto out)

There should really be no "hardware not ready" when the host router is
enumerated. Lets try to figure out what is happening there.

Can you enable tracing, reproduce and send me full dmesg + trace?

You can do it like:

# tbtrace enable

Then repro, and then:

# tbtrace disable
# tbtrace dump -vv > trace.out

and send me that and full dmesg.