On 3/3/22 14:04, Tom Rix wrote: > > On 3/2/22 4:35 PM, matthew.gerlach@xxxxxxxxxxxxxxx wrote: >> From: Matthew Gerlach <matthew.gerlach@xxxxxxxxxxxxxxx> >> >> Add documentation on identifying FPGA based PCI cards prompted >> by discussion on the linux-fpga@xxxxxxxxxxxxxxx mailing list. >> >> Signed-off-by: Matthew Gerlach <matthew.gerlach@xxxxxxxxxxxxxxx> >> --- >> 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. > > Why couldn't one of the old pci id's be reused ? > > How will the subvendor/subid be enforced ? > > 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 ? > > Tom > >> + >> Location of DFLs on a PCI Device >> ================================ >> The original method for finding a DFL on a PCI device assumed the start of the >
