Re: [PATCH v2] fpga: dfl: afu: support Rev 2 of DFL Port feature

[Xu Yilun]

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