[PATCH v2 0/2] Add PCIE device IDs for Intel DFL cards

[PATCH v2 0/2] Add PCIE device IDs for Intel DFL cards

[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

[PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation

[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

[PATCH v2 2/2] drivers: fpga: dfl-pci: Add PCIE device IDs for Intel DFL cards

[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

Re: [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation

[Tom Rix]

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

Re: [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation

[Russ Weight]

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
>

Re: [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation

[matthew.gerlach]

[-- 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
>>
>
>

RE: [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation

[Wu, Hao]

> 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

RE: [PATCH v2 2/2] drivers: fpga: dfl-pci: Add PCIE device IDs for Intel DFL cards

[Wu, Hao]

> 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

Re: [PATCH v2 1/2] Documentation: fpga: dfl: add PCI Identification documentation

[Tom Rix]

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
>>>
>>
>>