On Tue, Jan 30, 2024 at 10:00:16AM -0800, matthew.gerlach@xxxxxxxxxxxxxxx wrote: > > > On Tue, 30 Jan 2024, Xu Yilun wrote: > > > On Thu, Jan 25, 2024 at 03:37:15PM -0800, Matthew Gerlach wrote: > > > Revision 2 of the Device Feature List (DFL) Port feature > > > adds support for connecting the contents of the port to > > > multiple PCIe Physical Functions (PF). > > > > > > This new functionality requires changing the port reset > > > behavior during FPGA and software initialization from > > > revision 1 of the port feature. With revision 1, the initial > > > state of the logic inside the port was not guaranteed to > > > be valid until a port reset was performed by software during > > > driver initialization. With revision 2, the initial state > > > of the logic inside the port is guaranteed to be valid, > > > and a port reset is not required during driver initialization. > > > > > > This change in port reset behavior avoids a potential race > > > condition during PCI enumeration when a port is connected to > > > multiple PFs. Problems can occur if the driver attached to > > > the PF managing the port asserts reset in its probe function > > > when a driver attached to another PF accesses the port in its > > > own probe function. The potential problems include failed or hung > > > > Only racing during probe functions? I assume any time port_reset() > > would fail TLPs for the other PF. And port_reset() could be triggered > > at runtime by ioctl(). > > Yes, a port_reset() triggered by ioctl could result in failed TLP for the > other PFs. The user space SW performing the ioctl needs to ensure all PFs > involved are properly quiesced before the port_reset is performed. How would user get an insight into other PF drivers to know everything is quiesced? I mean do we need driver level management for this? Thanks, Yilun > > Do you want me to update the commit message with this information? > > Thanks, > Matthew
