On Wed, Nov 13, 2019 at 03:58:51PM -0600, Stuart Hayes wrote: > The hotplug port I'm seeing the issue with is an AMD "Starship/Matisse GPP > Bridge" (1022/1483), which uses an MSI interrupt (PCI-MSI chip). [...] > And because individual event enable bits in the slot control register aren't > cleared on each interrupt, I interpret this to mean that an interrupt message > will be sent every time that the event status bits in the slot status register > transition from all zeros to at least one event status bit being 1. Once one > of those event status bits is 1, the logical AND of the three conditions above > will not transition from FALSE to TRUE again until all of the (enabled) event > status bits in the slot status register all go to zero, which is what my patch > is intended to ensure. Understood now, thanks. I'd suggest adding a flag "unsigned int pvm_capable;" to struct controller below "u32 slot_cap" (in the "capabilities and quirks" section), setting that flag in pcie_init() from dev->msi_cap + PCI_MSI_FLAGS (& PCI_MSI_FLAGS_MASKBIT) and amending pciehp_isr() to check for that flag and re-read / re-write the Slot Status register until it's all zeroes. That would make the reason for the modifications to pciehp_isr() explicit. Please try to make the modifications to pciehp_isr() as small and simple as possible. Maybe it's worthwhile to put them in a separate static function which is called from pciehp_isr(), I don't know. Please mention the PCI vendor / device IDs in the commit message and provide a reference to the PCIe Base Spec section you've quoted above. Thanks, Lukas
