Re: [PATCH 2/2] thunderbolt: Don't resume the software CM if the host controller is gone

[Cole Leavitt <cole@unwrap.rs>]

Hi Mika,

On Mon, Oct 19, 2026 at 06:29:20AM +0200, Mika Westerberg wrote:
> This is not supposed to happen with SW CM systems. I've seen a couple of
> times Lenovo BIOS has the PCIe root port hotplug enabled and that's against
> what the Barlow Ridge BIOS configuration checklist says. Please check if
> there is newer BIOS (Lenovo has been fixing these) and of not report it to
> Lenovo.

Thanks, and sorry for the slow reply. You were right. Every oops I
captured was on BIOS N4FET30W (1.11), where pciehp was bound to the
Barlow Ridge root port (0000:80:1b.4, "pciehp: Slot(25)"). The machine
now runs N4FET52W (1.33), and that root port no longer gets the hotplug
service: only PME, AER and bandwidth control are bound to it. So the
slow-link "replacement" that started all of this cannot happen there
anymore.

Please drop this patch.

For 1/2: the trigger on this machine is gone with the new BIOS, but the
ordering problem is in pciehp itself. A device replacement detected in
pciehp_resume_noirq() still starts the removal from the IRQ thread in
the middle of the noirq phase, unserialized against ->resume_noirq() of
the drivers below the port (on today's mainline, fa4ad798f6f6,
pciehp_core.c:310 calls pciehp_request(), and pciehp_ctrl.c:145 wakes
the IRQ thread directly unless pciehp_poll_mode is set). Bjorn, Lukas:
if that is not worth changing without a reproducer on correctly
configured hardware, I will drop 1/2 as well.

Thanks,
Cole