On 9/25/20 10:47 AM, Sinan Kaya wrote:
On 9/25/2020 1:11 PM, Kuppuswamy, Sathyanarayanan wrote:
Why? Isn't DPC slot reset enough?
It will do the reset at hardware level. But driver state is not
cleaned up. So doing bus reset will restore both driver and
hardware states.
I really don't like this. If hotplug driver is restoring the state
and DPC driver is not; let's fix the DPC driver rather than causing
two resets and hope for the best.
One approach is to share the restore code between hotplug driver and
DPC driver.
If this is a too involved change, DPC driver should restore state
when hotplug is not supported.
Yes. we can add a condition for hotplug capability check.
DPC driver should be self-sufficient by itself.
Also for non-fatal errors, if reset is requested then we still need
some kind of bus reset call here
DPC should handle both fatal and non-fatal cases
Currently DPC is only triggered for FATAL errors.
and cause a bus reset
in hardware already before triggering an interrupt.
Error recovery is not triggered only DPC driver. AER also uses the
same error recovery code. If DPC is not supported, then we still need
reset logic.
I disagree that you need an additional reset on top of DPC reset.
Isn't one reset enough?
What will the second reset provide that first reset won't provide?
I see that you are trying to do the second reset only because second
reset restores state.
That looks like a short-term fix only to explode on the next iteration.
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
