On Thu, 13 Apr 2023 11:10:54 +0300 Ido Schimmel wrote: > I believe we are discussing three different issues: > > 1. Reset by PCI core when driver is bound to the device. > 2. Reset by PCI core when driver is not bound to the device. > 3. Reset by the driver itself during probe / devlink reload. > > These are my notes on each: > > 1. In this case, the reset_prepare() and reset_done() handlers of the > driver are invoked by the PCI core before and after the PCI reset. > Without them, if the used PCI reset method indeed reset the entire > device, then the driver and the device would be out of sync. I have > implemented these handlers for the driver: > https://github.com/idosch/linux/commit/28bc0dc06c01559c19331578bbba9f2b0460ab5d.patch > > 2. In this case, the handlers are not available and we only need to > ensure that the used PCI reset method reset the device. The method can > be a generic method such as "pm" or "bus" (which are available in my > case) or a "device_specific" method that is implemented in > drivers/pci/quirks.c by accessing the configuration space of the device. > > I need to check if one of the generic methods works for this device and > if not, check with the PCI team what we can do about it. > > 3. In this case, the driver already issues a reset via its command > interface during probe / devlink reload to ensure it is working with a > device in a clean state. The patch we are discussing merely adds another > reset method. Instead of starting the reset when the command is issued, > the reset will start after toggling the link on the downstream port. > > To summarize, I would like to proceed as follows: > > 1. Submit the following patch that implements the PCI reset handlers for > the device: > https://github.com/idosch/linux/commit/28bc0dc06c01559c19331578bbba9f2b0460ab5d.patch I'm probably confused but does this mean that PCI reset would impact the datapath? From the commit message it sounded like the new reset is harder than the previous one.
