On Wed, Mar 17, 2021 at 10:45:21AM -0700, Dan Williams wrote:
> Ah, ok, we're missing a flush of the hotplug event handler after the
> link is up to make sure the hotplug handler does not see the Link Up.
> I'm not immediately seeing how the new proposal ensures that there is
> no Link Up event still in flight after DPC completes its work.
> Wouldn't it be required to throw away Link Up to Link Up transitions?
If you look at the new code added to pciehp_ist() by my patch...
atomic_and(~PCI_EXP_SLTSTA_DLLSC, &ctrl->pending_events);
if (pciehp_check_link_active(ctrl) > 0)
events &= ~PCI_EXP_SLTSTA_DLLSC;
... the atomic_and() ignores the Link Up event which was picked
up by the hardirq handler pciehp_isr() while pciehp_ist() waited for
link recovery. Afterwards, the Link Down event is only ignored if the
link is still up: If the link has gone down again before the call to
pciehp_check_link_active(), that event is honored immediately (because
the DLLSC event is then not filtered). If it goes down after the call,
that event will be picked up by pciehp_isr(). Thus, only the DLLSC
events caused by DPC are ignored, but no others.
A DLLSC event caused by surprise removal during DPC may be incorrectly
ignored, but the expectation is that the ensuing Presence Detect Changed
event will still cause bringdown of the slot after DPC has completed.
Hardware does exist which erroneously hardwires Presence Detect to zero,
but that's rare and DPC-capable systems are likely not affected.
I've realized today that I forgot to add a "synchronize_hardirq(irq);"
before the call to atomic_and(). Sorry, that will be fixed in the
next iteration.
Thanks,
Lukas
