On Fri, 4 Mar 2022, Russ Weight wrote: > > > On 3/3/22 14:04, Tom Rix wrote: >> >> On 3/2/22 4:35 PM, matthew.gerlach@linux.intel.com wrote: >>> From: Matthew Gerlach >>> >>> Add documentation on identifying FPGA based PCI cards prompted >>> by discussion on the linux-fpga@vger.kernel.org mailing list. >>> >>> Signed-off-by: Matthew Gerlach >>> --- >>> v2: Introduced in v2. >>> --- >>>   Documentation/fpga/dfl.rst | 20 ++++++++++++++++++++ >>>   1 file changed, 20 insertions(+) >>> >>> diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst >>> index ef9eec71f6f3..5fb2ca8e76d7 100644 >>> --- a/Documentation/fpga/dfl.rst >>> +++ b/Documentation/fpga/dfl.rst >>> @@ -502,6 +502,26 @@ Developer only needs to provide a sub feature driver with matched feature id. >>>   FME Partial Reconfiguration Sub Feature driver (see drivers/fpga/dfl-fme-pr.c) >>>   could be a reference. >>>   +PCI Device Identification >>> +================================ >>> +Since FPGA based PCI cards can be reconfigured to a perform a completely >>> +new function at runtime, properly identifying such cards and binding the >>> +correct driver can be challenging. In many use cases, deployed FPGA based >>> +PCI cards are essentially static and the PCI Product ID and Vendor ID pair >>> +is sufficient to identify the card.  The DFL framework helps with the >>> +dynamic case of deployed FPGA cards changing at run time by providing >>> +more detailed information about card discoverable at runtime. >>> + >>> +At one level, the DFL on a PCI card describes the function of the card. >>> +However, the same DFL could be instantiated on different physical cards. >>> +Conversely, different DFLs could be instantiated on the same physical card. >>> +Practical management of a cloud containing a heterogeneous set of such cards >>> +requires a PCI level of card identification. While the PCI Product ID and >>> +Vendor ID may be sufficient to bind the dfl-pci driver, it is expected >>> +that FPGA PCI cards would advertise suitable Subsystem ID and Subsystem >>> +Vendor ID values. PCI Vital Product Data (VPD) can also be used for >>> +more granular information about the board. >> >> This describes a bit more of the problem, it should describe it wrt ofs dev id. The introduction of the ofs dev should be explicitly called out as a generic pci id. The problem I'm describing exists for all FPGA based PCI cards; so I am purposely trying to be abstract as much as possible. >> >> Why couldn't one of the old pci id's be reused ? Yes, old pci id's could be reused, and people have done just that. We thought a new PCI ID would minimize confusion with cards that have already been deployed. >> >> How will the subvendor/subid be enforced ? Subvendor and Subid are managed just like any other PCI card with or without a FPGA. >> >> Is the current security manager patchset smart enough to save the board from being bricked when a user doesn't look beyond the pci id ? > > Yes - the security manager is invoked based of DFL feature ID and revision, and the functionality is differentiated based on the same information. > >> >> What happens if a board uses this device id but doesn't have a max10 to do the update ? If a board doesn't have a max10, then there will be no DFH for a max10 in the board's DFLs. Presumeably, the board would need some update process, and an approprate DFH would be in that board's DFL. >> >> Tom >> >>> + >>>   Location of DFLs on a PCI Device >>>   ================================ >>>   The original method for finding a DFL on a PCI device assumed the start of the >> > >