On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote: > If a bridge supports hotplug and observes a PCIe fatal error, the following > events happen: > > 1. AER driver removes the devices from PCI tree on fatal error > 2. AER driver brings down the link by issuing a secondary bus reset waits > for the link to come up. > 3. Hotplug driver observes a link down interrupt > 4. Hotplug driver tries to remove the devices waiting for the rescan lock > but devices are already removed by the AER driver and AER driver is waiting > for the link to come back up. > 5. AER driver tries to re-enumerate devices after polling for the link > state to go up. > 6. Hotplug driver obtains the lock and tries to remove the devices again. > > If a bridge is a hotplug capable bridge, mask hotplug interrupts before the > reset and unmask afterwards. Would it work for you if you just amended the AER driver to skip removal and re-enumeration of devices if the port is a hotplug bridge? Just check for is_hotplug_bridge in struct pci_dev. That would seem like a much simpler solution, given that it is known that the link will flap on reset, causing the hotplug driver to remove and re-enumerate devices. That would also cover cases where hotplug is handled by a different driver than pciehp, or by the platform firmware. Thanks, Lukas -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
