* [PATCH v2 0/2] Add PCIE device IDs for Intel DFL cards @ 2022-03-03 0:35 matthew.gerlach 2022-03-03 0:35 ` [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation matthew.gerlach 2022-03-03 0:35 ` [PATCH v2 2/2] drivers: fpga: dfl-pci: Add PCIE device IDs for Intel DFL cards matthew.gerlach 0 siblings, 2 replies; 9+ messages in thread From: matthew.gerlach @ 2022-03-03 0:35 UTC (permalink / raw) To: hao.wu, yilun.xu, russell.h.weight, basheer.ahmed.muddebihal, trix, mdf, corbet, linux-fpga, linux-doc, linux-kernel, dan.j.williams, ashok.raj, tianfei.zhang Cc: Matthew Gerlach From: Matthew Gerlach <matthew.gerlach@linux.intel.com> This patch set adds the PCIE device IDs for Intel cards with Device Feature Lists (DFL) to the pci_dev_table for the dfl-pci driver. This patch set was separated for clarity from a larger patch set submitted by tianfei.zhang@intel.com. Patch 1 adds documentation about identifying PCIE FPGA cards with Device Feature Lists (DFL). Patch 2 adds the device ids to the pci_dev_table for the dfl-pci driver. Matthew Gerlach (2): Documentation: fpga: dfl: add PCI Identification documentation drivers: fpga: dfl-pci: Add PCIE device IDs for Intel DFL cards Documentation/fpga/dfl.rst | 20 ++++++++++++++++++++ drivers/fpga/dfl-pci.c | 4 ++++ 2 files changed, 24 insertions(+) -- 2.25.1 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation 2022-03-03 0:35 [PATCH v2 0/2] Add PCIE device IDs for Intel DFL cards matthew.gerlach @ 2022-03-03 0:35 ` matthew.gerlach 2022-03-03 22:04 ` Tom Rix 2022-03-11 4:16 ` Wu, Hao 2022-03-03 0:35 ` [PATCH v2 2/2] drivers: fpga: dfl-pci: Add PCIE device IDs for Intel DFL cards matthew.gerlach 1 sibling, 2 replies; 9+ messages in thread From: matthew.gerlach @ 2022-03-03 0:35 UTC (permalink / raw) To: hao.wu, yilun.xu, russell.h.weight, basheer.ahmed.muddebihal, trix, mdf, corbet, linux-fpga, linux-doc, linux-kernel, dan.j.williams, ashok.raj, tianfei.zhang Cc: Matthew Gerlach From: Matthew Gerlach <matthew.gerlach@linux.intel.com> 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 <matthew.gerlach@linux.intel.com> --- 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. + Location of DFLs on a PCI Device ================================ The original method for finding a DFL on a PCI device assumed the start of the -- 2.25.1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation 2022-03-03 0:35 ` [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation matthew.gerlach @ 2022-03-03 22:04 ` Tom Rix 2022-03-04 16:45 ` Russ Weight 2022-03-11 4:16 ` Wu, Hao 1 sibling, 1 reply; 9+ messages in thread From: Tom Rix @ 2022-03-03 22:04 UTC (permalink / raw) To: matthew.gerlach, hao.wu, yilun.xu, russell.h.weight, basheer.ahmed.muddebihal, mdf, corbet, linux-fpga, linux-doc, linux-kernel, dan.j.williams, ashok.raj, tianfei.zhang On 3/2/22 4:35 PM, matthew.gerlach@linux.intel.com wrote: > From: Matthew Gerlach <matthew.gerlach@linux.intel.com> > > 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 <matthew.gerlach@linux.intel.com> > --- > 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 ? 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation 2022-03-03 22:04 ` Tom Rix @ 2022-03-04 16:45 ` Russ Weight 2022-03-04 18:30 ` matthew.gerlach 0 siblings, 1 reply; 9+ messages in thread From: Russ Weight @ 2022-03-04 16:45 UTC (permalink / raw) To: Tom Rix, matthew.gerlach, hao.wu, yilun.xu, basheer.ahmed.muddebihal, mdf, corbet, linux-fpga, linux-doc, linux-kernel, dan.j.williams, ashok.raj, tianfei.zhang 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 <matthew.gerlach@linux.intel.com> >> >> 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 <matthew.gerlach@linux.intel.com> >> --- >> 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 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation 2022-03-04 16:45 ` Russ Weight @ 2022-03-04 18:30 ` matthew.gerlach 2022-03-22 17:11 ` Tom Rix 0 siblings, 1 reply; 9+ messages in thread From: matthew.gerlach @ 2022-03-04 18:30 UTC (permalink / raw) To: Russ Weight Cc: Tom Rix, hao.wu, yilun.xu, basheer.ahmed.muddebihal, mdf, corbet, linux-fpga, linux-doc, linux-kernel, dan.j.williams, ashok.raj, tianfei.zhang [-- Attachment #1: Type: text/plain, Size: 3691 bytes --] 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 <matthew.gerlach@linux.intel.com> >>> >>> 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 <matthew.gerlach@linux.intel.com> >>> --- >>> 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 >> > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation 2022-03-04 18:30 ` matthew.gerlach @ 2022-03-22 17:11 ` Tom Rix 0 siblings, 0 replies; 9+ messages in thread From: Tom Rix @ 2022-03-22 17:11 UTC (permalink / raw) To: matthew.gerlach, Russ Weight Cc: hao.wu, yilun.xu, basheer.ahmed.muddebihal, mdf, corbet, linux-fpga, linux-doc, linux-kernel, dan.j.williams, ashok.raj, tianfei.zhang On 3/4/22 10:30 AM, matthew.gerlach@linux.intel.com wrote: > > > 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 <matthew.gerlach@linux.intel.com> >>>> >>>> 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 <matthew.gerlach@linux.intel.com> >>>> --- >>>> 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. Reviewing how the kernel uses subvendor and subsystem shows it is not widely used. And when it is, it is used to isolate small variations or hw problems in the device, not completely unique cards There are very few subsytem/subvendor's in pci_id.h, the usual case seems to be hardcoded hex. So there is no enforcement. I can not see how this generic id would not be abused by vendors nor how it would not be confusing to the end users. Tom > >>> >>> 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 >>> >> >> ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation 2022-03-03 0:35 ` [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation matthew.gerlach 2022-03-03 22:04 ` Tom Rix @ 2022-03-11 4:16 ` Wu, Hao 1 sibling, 0 replies; 9+ messages in thread From: Wu, Hao @ 2022-03-11 4:16 UTC (permalink / raw) To: matthew.gerlach, Xu, Yilun, Weight, Russell H, Muddebihal, Basheer Ahmed, trix, mdf, corbet, linux-fpga, linux-doc, linux-kernel, Williams, Dan J, Raj, Ashok, Zhang, Tianfei > Subject: [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification > documentation > > From: Matthew Gerlach <matthew.gerlach@linux.intel.com> > > 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 <matthew.gerlach@linux.intel.com> > --- > 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. I think PCI Device/Card Identification is out of scope of DFL. DFL is another level concept, it can't help to identify which card it is. There is no additional requirement to users, they can choose any method they want, and they don't have to reuse dfl-pci for their own cards. > + > Location of DFLs on a PCI Device > ================================ > The original method for finding a DFL on a PCI device assumed the start of the > -- > 2.25.1 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v2 2/2] drivers: fpga: dfl-pci: Add PCIE device IDs for Intel DFL cards 2022-03-03 0:35 [PATCH v2 0/2] Add PCIE device IDs for Intel DFL cards matthew.gerlach 2022-03-03 0:35 ` [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation matthew.gerlach @ 2022-03-03 0:35 ` matthew.gerlach 2022-03-11 4:20 ` Wu, Hao 1 sibling, 1 reply; 9+ messages in thread From: matthew.gerlach @ 2022-03-03 0:35 UTC (permalink / raw) To: hao.wu, yilun.xu, russell.h.weight, basheer.ahmed.muddebihal, trix, mdf, corbet, linux-fpga, linux-doc, linux-kernel, dan.j.williams, ashok.raj, tianfei.zhang Cc: Matthew Gerlach From: Matthew Gerlach <matthew.gerlach@linux.intel.com> Add the PCIE device IDs for Intel cards with Device Feature Lists (DFL) to the pci_dev_table for the dfl-pci driver. Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> Signed-off-by: Tianfei Zhang <tianfei.zhang@intel.com> --- v2: changed names from INTEL_OFS to INTEL_DFL --- drivers/fpga/dfl-pci.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl-pci.c index 717ac9715970..8faf284509e7 100644 --- a/drivers/fpga/dfl-pci.c +++ b/drivers/fpga/dfl-pci.c @@ -77,12 +77,14 @@ static void cci_pci_free_irq(struct pci_dev *pcidev) #define PCIE_DEVICE_ID_INTEL_PAC_D5005 0x0B2B #define PCIE_DEVICE_ID_SILICOM_PAC_N5010 0x1000 #define PCIE_DEVICE_ID_SILICOM_PAC_N5011 0x1001 +#define PCIE_DEVICE_ID_INTEL_DFL 0xbcce /* VF Device */ #define PCIE_DEVICE_ID_VF_INT_5_X 0xBCBF #define PCIE_DEVICE_ID_VF_INT_6_X 0xBCC1 #define PCIE_DEVICE_ID_VF_DSC_1_X 0x09C5 #define PCIE_DEVICE_ID_INTEL_PAC_D5005_VF 0x0B2C +#define PCIE_DEVICE_ID_INTEL_DFL_VF 0xbccf static struct pci_device_id cci_pcie_id_tbl[] = { {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCIE_DEVICE_ID_PF_INT_5_X),}, @@ -96,6 +98,8 @@ static struct pci_device_id cci_pcie_id_tbl[] = { {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCIE_DEVICE_ID_INTEL_PAC_D5005_VF),}, {PCI_DEVICE(PCI_VENDOR_ID_SILICOM_DENMARK, PCIE_DEVICE_ID_SILICOM_PAC_N5010),}, {PCI_DEVICE(PCI_VENDOR_ID_SILICOM_DENMARK, PCIE_DEVICE_ID_SILICOM_PAC_N5011),}, + {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCIE_DEVICE_ID_INTEL_DFL),}, + {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCIE_DEVICE_ID_INTEL_DFL_VF),}, {0,} }; MODULE_DEVICE_TABLE(pci, cci_pcie_id_tbl); -- 2.25.1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* RE: [PATCH v2 2/2] drivers: fpga: dfl-pci: Add PCIE device IDs for Intel DFL cards 2022-03-03 0:35 ` [PATCH v2 2/2] drivers: fpga: dfl-pci: Add PCIE device IDs for Intel DFL cards matthew.gerlach @ 2022-03-11 4:20 ` Wu, Hao 0 siblings, 0 replies; 9+ messages in thread From: Wu, Hao @ 2022-03-11 4:20 UTC (permalink / raw) To: matthew.gerlach, Xu, Yilun, Weight, Russell H, Muddebihal, Basheer Ahmed, trix, mdf, corbet, linux-fpga, linux-doc, linux-kernel, Williams, Dan J, Raj, Ashok, Zhang, Tianfei > Subject: [PATCH v2 2/2] drivers: fpga: dfl-pci: Add PCIE device IDs for Intel DFL > cards Please remove "drivers" > > From: Matthew Gerlach <matthew.gerlach@linux.intel.com> > > Add the PCIE device IDs for Intel cards with Device Feature Lists > (DFL) to the pci_dev_table for the dfl-pci driver. > > Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> > Signed-off-by: Tianfei Zhang <tianfei.zhang@intel.com> > --- > v2: changed names from INTEL_OFS to INTEL_DFL > --- > drivers/fpga/dfl-pci.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl-pci.c > index 717ac9715970..8faf284509e7 100644 > --- a/drivers/fpga/dfl-pci.c > +++ b/drivers/fpga/dfl-pci.c > @@ -77,12 +77,14 @@ static void cci_pci_free_irq(struct pci_dev *pcidev) > #define PCIE_DEVICE_ID_INTEL_PAC_D5005 0x0B2B > #define PCIE_DEVICE_ID_SILICOM_PAC_N5010 0x1000 > #define PCIE_DEVICE_ID_SILICOM_PAC_N5011 0x1001 > +#define PCIE_DEVICE_ID_INTEL_DFL 0xbcce > > /* VF Device */ > #define PCIE_DEVICE_ID_VF_INT_5_X 0xBCBF > #define PCIE_DEVICE_ID_VF_INT_6_X 0xBCC1 > #define PCIE_DEVICE_ID_VF_DSC_1_X 0x09C5 > #define PCIE_DEVICE_ID_INTEL_PAC_D5005_VF 0x0B2C > +#define PCIE_DEVICE_ID_INTEL_DFL_VF 0xbccf > > static struct pci_device_id cci_pcie_id_tbl[] = { > {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCIE_DEVICE_ID_PF_INT_5_X),}, > @@ -96,6 +98,8 @@ static struct pci_device_id cci_pcie_id_tbl[] = { > {PCI_DEVICE(PCI_VENDOR_ID_INTEL, > PCIE_DEVICE_ID_INTEL_PAC_D5005_VF),}, > {PCI_DEVICE(PCI_VENDOR_ID_SILICOM_DENMARK, > PCIE_DEVICE_ID_SILICOM_PAC_N5010),}, > {PCI_DEVICE(PCI_VENDOR_ID_SILICOM_DENMARK, > PCIE_DEVICE_ID_SILICOM_PAC_N5011),}, > + {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCIE_DEVICE_ID_INTEL_DFL),}, > + {PCI_DEVICE(PCI_VENDOR_ID_INTEL, > PCIE_DEVICE_ID_INTEL_DFL_VF),}, > {0,} Actually we never know if future devices will pick this id or not, so we don't have to enforce such a "generic" id and name here. Hm.. Maybe just OFS, I guess that if you have a newer generation card than OFS, you may probably want to use a new ID for the same reason that you don't pick the existing ones. : ) How do you think? Thanks Hao > }; > MODULE_DEVICE_TABLE(pci, cci_pcie_id_tbl); > -- > 2.25.1 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-03-22 17:11 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-03-03 0:35 [PATCH v2 0/2] Add PCIE device IDs for Intel DFL cards matthew.gerlach 2022-03-03 0:35 ` [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation matthew.gerlach 2022-03-03 22:04 ` Tom Rix 2022-03-04 16:45 ` Russ Weight 2022-03-04 18:30 ` matthew.gerlach 2022-03-22 17:11 ` Tom Rix 2022-03-11 4:16 ` Wu, Hao 2022-03-03 0:35 ` [PATCH v2 2/2] drivers: fpga: dfl-pci: Add PCIE device IDs for Intel DFL cards matthew.gerlach 2022-03-11 4:20 ` Wu, Hao
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).