On 9/25/2020 1:11 AM, Kuppuswamy, Sathyanarayanan wrote: > > > On 9/24/20 1:52 PM, Sinan Kaya wrote: >> On 9/24/2020 12:06 AM, Kuppuswamy, Sathyanarayanan wrote: >> >> So, this is a matter of moving the save/restore logic from the hotplug >> driver into common code so that DPC slot reset takes advantage of it? > We are not moving it out of hotplug path. But fixing it in this code path. > With this fix, we will not depend on hotplug driver to restore the state. Any possibility of unification? [snip] >> >>> To fix above issues, use PCI_ERS_RESULT_NEED_RESET as error state after >>> successful reset_link() operation. This will ensure ->slot_reset() be >>> called after reset_link() operation for fatal errors. >> >> You lost me here. Why do we want to do secondary bus reset on top of >> DPC reset? > For non-hotplug capable slots, when reset (PCI_ERS_RESULT_NEED_RESET) is > requested, we want to reset it before calling ->slot_reset() callback. Why? Isn't DPC slot reset enough? What will bus reset do that DPC slot reset won't do? I can understand calling bus reset if DPC is not supported. I don't understand the requirement to do double reset.
