On 9/25/20 9:55 AM, Sinan Kaya wrote:
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?
If we do that, it might need rework of hotplug driver. It will be a big
change. IMO, its better not to touch that bee hive.
[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?
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.
Also for non-fatal errors, if reset is requested then we still need
some kind of bus reset call here.
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.
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
