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

[Lukas Wunner]

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

I think the proper solution is to hold the device_lock() in
device_resume_noirq(), i.e. this needs to be addressed in the
driver core's device power management code, not in pciehp or
individual device drivers.

However as you're saying there's no reproducer anymore and
changing device_resume_noirq() is a bit risky.

Thanks,

Lukas