From: Cole Leavitt <cole@unwrap.rs>
To: Bjorn Helgaas <bhelgaas@google.com>,
Mika Westerberg <westeri@kernel.org>
Cc: "Cole Leavitt" <cole@unwrap.rs>, "Lukas Wunner" <lukas@wunner.de>,
"Andreas Noever" <andreas.noever@gmail.com>,
"Yehezkel Bernat" <YehezkelShB@gmail.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
linux-pci@vger.kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH 2/2] thunderbolt: Don't resume the software CM if the host controller is gone
Date: Sun, 18 Oct 2026 12:39:08 -0400 [thread overview]
Message-ID: <20261018163910.132231-2-cole@unwrap.rs> (raw)
In-Reply-To: <20261018163910.132231-1-cole@unwrap.rs>
nhi_resume_noirq() sets nhi->going_away when the host controller is not
present anymore on resume (commit bdccf295d7cd ("thunderbolt: Do not
touch the hardware if the NHI is gone on resume")). With going_away set
tb_ring_start() refuses to start the control channel rings, but the
software connection manager's tb_resume_noirq() still goes through the
whole resume sequence. Every control channel request then fails with
-ESHUTDOWN from __tb_ring_enqueue(), and tb_cfg_read()/tb_cfg_write()
WARN for each one:
tb_cfg_write: -108
WARNING: drivers/thunderbolt/ctl.c:1157 at tb_cfg_write+0x94/0xf0 [thunderbolt]
Call Trace:
tb_switch_configure+0x8f/0x1d0 [thunderbolt]
tb_switch_resume+0xb9/0x3d0 [thunderbolt]
tb_resume_noirq+0x5d/0x2e0 [thunderbolt]
tb_domain_resume_noirq+0x42/0x60 [thunderbolt]
...
tb_cfg_read: -108
WARNING: drivers/thunderbolt/ctl.c:1131 at tb_cfg_read+0x94/0xf0 [thunderbolt]
...
thunderbolt 0000:8a:00.0: 0: failed to restore TMU configuration
This happens on a discrete Barlow Ridge host when the root port link
does not come back in time on resume from s2idle: pciehp marks the
subtree disconnected in pciehp_resume_noirq(), so pci_device_is_present()
returns false for the NHI and the (about to be removed) domain is then
"resumed" through dead rings.
The firmware connection manager already honors the flag in
icm_complete(). Do the same in the software connection manager and skip
tb_resume_noirq() when the host controller is gone. The domain is torn
down when the controller is removed, and hotplug_active stays false so
no events are processed in the meantime.
Fixes: bdccf295d7cd ("thunderbolt: Do not touch the hardware if the NHI is gone on resume")
Cc: stable@vger.kernel.org
Signed-off-by: Cole Leavitt <cole@unwrap.rs>
---
Notes:
Tested on a Lenovo ThinkPad P16 Gen 3 (Core Ultra 9 275HX, JHL9580
Barlow Ridge host, I226 Ethernet), in daily use with s2idle since
2026-09-17.
drivers/thunderbolt/tb.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
index 4e5d0578fd4b..d236de1e5568 100644
--- a/drivers/thunderbolt/tb.c
+++ b/drivers/thunderbolt/tb.c
@@ -3177,6 +3177,19 @@ static int tb_resume_noirq(struct tb *tb)
unsigned int usb3_delay = 0;
LIST_HEAD(tunnels);
+ /*
+ * The host controller is gone (for example the last device was
+ * unplugged, or the PCIe hotplug driver found the controller
+ * removed or replaced during system sleep). The control channel
+ * rings are not started in that case so every config space access
+ * below would just fail. Leave the domain as is; it is torn down
+ * when the controller is removed.
+ */
+ if (tb->nhi->going_away) {
+ tb_dbg(tb, "host controller not present, skipping resume\n");
+ return 0;
+ }
+
tb_dbg(tb, "resuming...\n");
/*
--
2.54.0
next prev parent reply other threads:[~2026-10-18 16:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-18 16:37 [PATCH 0/2] PCI: pciehp / thunderbolt: Fix resume with a slow Thunderbolt host link Cole Leavitt
2026-10-18 16:39 ` [PATCH 1/2] PCI: pciehp: Defer device replacement handling until ->resume() Cole Leavitt
2026-10-18 16:39 ` Cole Leavitt [this message]
2026-10-18 16:45 ` [PATCH 2/2] thunderbolt: Don't resume the software CM if the host controller is gone sashiko-bot
2026-10-18 16:47 ` [PATCH 1/2] PCI: pciehp: Defer device replacement handling until ->resume() sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261018163910.132231-2-cole@unwrap.rs \
--to=cole@unwrap.rs \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=bhelgaas@google.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=westeri@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox