In OFS legacy model, there is only 1 Port device related to
1 VF, the flag DFL_FEAT_PORT_CONNECTED_AFU will take notes for
this model. In legacy model, it need to check the released port
number match VF device number or not. But in "Multiple VFs per
PR slot" model, the Port device would not connected to AFU/PR
slot, so we don't need to release the Port device before creating
the VFs.
Signed-off-by: Matthew Gerlach <[email protected]>
Signed-off-by: Tianfei zhang <[email protected]>
---
drivers/fpga/dfl.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index 5872031c2e9f..fd04ef5c8b03 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -1702,11 +1702,13 @@ int dfl_fpga_cdev_config_ports_vf(struct dfl_fpga_cdev *cdev, int num_vfs)
mutex_lock(&cdev->lock);
/*
- * can't turn multiple ports into 1 VF device, only 1 port for 1 VF
- * device, so if released port number doesn't match VF device number,
- * then reject the request with -EINVAL error code.
+ * In the OFS legacy model, it can't turn multiple ports into 1 VF
+ * device, because only 1 port conneced to 1 VF device, so if released
+ * port number doesn't match VF device number, then reject the request
+ * with -EINVAL error code.
*/
- if (cdev->released_port_num != num_vfs) {
+ if ((cdev->features & DFL_FEAT_PORT_CONNECTED_AFU) &&
+ cdev->released_port_num != num_vfs) {
ret = -EINVAL;
goto done;
}
--
2.26.2
> Subject: [PATCH v3 3/5] fpga: dfl: fix VF creation in OFS
Why this is a fix?
>
> In OFS legacy model, there is only 1 Port device related to
> 1 VF, the flag DFL_FEAT_PORT_CONNECTED_AFU will take notes for
> this model.
What is OFS legacy model? And what is legacy model? They are
the same or not? It's quite confusing.
> In legacy model, it need to check the released port
> number match VF device number or not. But in "Multiple VFs per
> PR slot" model, the Port device would not connected to AFU/PR
> slot, so we don't need to release the Port device before creating
> the VFs.
I think the major difference here is not that PORT has AFU or not, but
If PORT needs to be turned into VFs. Would it be better to be decided
by FME registers controlling the access to PORT?
If we consider following same flow for enable SRIOV to reuse existing
tools, then we need to add FME flags to indicate user (and dfl-pci),
no need to assign/release port for SRIOV enabling.
Hao
>
> Signed-off-by: Matthew Gerlach <[email protected]>
> Signed-off-by: Tianfei zhang <[email protected]>
> ---
> drivers/fpga/dfl.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index 5872031c2e9f..fd04ef5c8b03 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -1702,11 +1702,13 @@ int dfl_fpga_cdev_config_ports_vf(struct
> dfl_fpga_cdev *cdev, int num_vfs)
>
> mutex_lock(&cdev->lock);
> /*
> - * can't turn multiple ports into 1 VF device, only 1 port for 1 VF
> - * device, so if released port number doesn't match VF device number,
> - * then reject the request with -EINVAL error code.
> + * In the OFS legacy model, it can't turn multiple ports into 1 VF
> + * device, because only 1 port conneced to 1 VF device, so if released
> + * port number doesn't match VF device number, then reject the request
> + * with -EINVAL error code.
> */
> - if (cdev->released_port_num != num_vfs) {
> + if ((cdev->features & DFL_FEAT_PORT_CONNECTED_AFU) &&
> + cdev->released_port_num != num_vfs) {
> ret = -EINVAL;
> goto done;
> }
> --
> 2.26.2