Re: [PATCH RFC v3 4/5] PCI: pciehp: Report surprise removal from pciehp_isr()

[sashiko-bot@kernel.org]

> A surprise removal during a safe removal cannot be reported: the
> removal blocks waiting on a device interrupt or status read, and the
> single-threaded IRQ thread is itself executing that removal, so it
> cannot report that the device is gone. The removal hangs.
> 
> The hardirq handler pciehp_isr() still runs while the IRQ thread is
> blocked, so it can report the disconnect. However, pciehp_ist()
> deliberately ignores link and presence changes caused by a Secondary
> Bus Reset or Downstream Port Containment, where the device is only
> temporarily inaccessible. Distinguishing those normally requires
> waiting for the SBR or DPC to conclude, which takes seconds and is not
> possible in hardirq context.
> 
> Schedule a work item from pciehp_isr() when a PDC or DLLSC event
> arrives and neither Presence Detect State nor Data Link Layer Link
> Active indicates that a card is present.
> This provides us a pathway to wait/block/sleep as we will not be
> in pciehp_isr().
> 
> In pciehp_disconnect_work(), wait for the DPC recovery or SBR to complete
> before checking presence and not consume the link change flags, so that
> pciehp_ist() can still see them and ignore the link change if it was
> caused by a DPC or SBR. Even after the DPC or SBR has completed, if the
> device is really gone then pciehp_disconnect_work() will see that and
> report the surprise removal. Like pciehp_ist(), it holds a runtime PM
> reference on the port and checks presence under reset_lock, since a
> slot reset may make Presence Detect State and Link Active flap.
> 
> Link: https://lore.kernel.org/all/aHlZE18kPuHuDtTT@wunner.de/
> Signed-off-by: Abhin Parekadan Jose <abhinjoses@gmail.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260927175203.928270-1-abhinjoses@gmail.com?part=4