On Mon, Mar 12, 2018 at 09:04:47PM +0530, poza@xxxxxxxxxxxxxx wrote: > On 2018-03-12 20:28, Keith Busch wrote: > > I'm not sure I understand. The link is disabled while DPC is triggered, > > so if anything, you'd want to un-enumerate everything below the > > contained > > port (that's what it does today). > > > > After releasing a slot from DPC, the link is allowed to retrain. If > > there > > is a working device on the other side, a link up event occurs. That > > event is handled by the pciehp driver, and that schedules enumeration > > no matter what you do to the DPC driver. > > yes, that is what i current, but this patch-set makes DPC aware of error > handling driver callbacks. I've been questioning the utility of doing that since the very first version of this patch set. > besides, in absence of pciehp there is nobody to do enumeration. If you configure your kernel to not have a feature, you don't get to expect the feature works. You can still manually rescan through sysfs, /sys/bus/pci/rescan. > And, I was talking about pci_stop_and_remove_bus_device() in dpc. > if DPC calls driver's error callbacks, is it required to stop the devices ? DPC is PCIe's preferred surprise removal mechanism. If you don't want the DPC driver to handle removing devices downstream the containment, how do you want those devices get removed? Just calling driver's error callbacks leaves the kernel's view of the topology in the wrong state.
