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

[Bjorn Helgaas <helgaas@kernel.org>]

On Sun, Nov 08, 2026 at 12:18:29AM -0500, Cole Leavitt wrote:
> 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.

It sounds like there may still be an ordering issue in pciehp, but I
would want a Reviewed-by from Lukas before applying patch 1/2 ("PCI:
pciehp: Defer device replacement handling until ->resume()")