Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Wu, Hao" <hao.wu@intel.com>
To:     "Zhang, Tianfei" <tianfei.zhang@intel.com>,
        "trix@redhat.com" <trix@redhat.com>,
        "mdf@kernel.org" <mdf@kernel.org>,
        "Xu, Yilun" <yilun.xu@intel.com>,
        "linux-fpga@vger.kernel.org" <linux-fpga@vger.kernel.org>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "corbet@lwn.net" <corbet@lwn.net>,
        Matthew Gerlach <matthew.gerlach@linux.intel.com>
Subject: RE: [PATCH v3 3/5] fpga: dfl: fix VF creation in OFS
Thread-Topic: [PATCH v3 3/5] fpga: dfl: fix VF creation in OFS
Thread-Index: AQHYLTUS/+ljxhhcjkaVJJIxo1vmsqyqGXjw
Date:   Tue, 1 Mar 2022 07:13:26 +0000
Message-ID: <DM6PR11MB3819DB26C00B07D058B7A65C85029@DM6PR11MB3819.namprd11.prod.outlook.com>
References: <20220301062123.818687-1-tianfei.zhang@intel.com>
 <20220301062123.818687-4-tianfei.zhang@intel.com>
In-Reply-To: <20220301062123.818687-4-tianfei.zhang@intel.com>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-reaction: no-action
dlp-version: 11.6.401.20
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?uMnk7MwrFjI21xJoQ5cu+smErRUoq7QtpokzdKFAKXA+UxAkfVDgLXD3Ob7k?=
 =?us-ascii?Q?jr5chgvjYivf5fwIfhynNhyLqXiTJik8mCmVQSdP8UvNiMX8OjwbmgZTYBP7?=
 =?us-ascii?Q?lVwGSGgIQDyX3ks8IwCNDqP2lSsLfRYdTRt/5YKtPssfUecOXZ7eql+bji3Q?=
 =?us-ascii?Q?Ornht25h00E+D63inctbprmEwDs4t0LSJksMNwHGWXr6WrZU742agwxaNQbH?=
 =?us-ascii?Q?oWNrTKLKH98u4xNDa8iluvSM3T3Dl7TwcZg9tR4G3pWw66EwJFy/0h4kbTZk?=
 =?us-ascii?Q?XjI6SoVBtl7L6wO6CVTjIsbT6ose0WUyajILdW2SzfQ7C67TC/lv81jEck6P?=
 =?us-ascii?Q?fLqiMQQrBsH/07TzIrHnpjXEPVXuDYzzFXfLqM6OYxAj0ojnJDX1xFZ7CGSr?=
 =?us-ascii?Q?6CbJp3EFNtmWiWLPD43C8Q342ybtWKgfc967tmxVPr5DVy4UFZXJ2Bwj7TbT?=
 =?us-ascii?Q?R7fN0tVxymrzI6MW80EJIJCZ5Py7dipI0fyljYP/f6a65EY4IPcIISE399t5?=
 =?us-ascii?Q?65lzn7eLeoBEn3mX8Tm35OEljwrACChTRgjSEYqWCDydNXD6UzBhc2n5RKi5?=
 =?us-ascii?Q?TKuGXWUDxWmXiVLJ7m1Y+oqXcBmlEN4NEd2Dn67whJ9NPHnGAAS7eU89O0R2?=
 =?us-ascii?Q?1jeQlcfpIYeqqpqdH0KfpTonJRO7uwyQ6fcNIYAHZXvGWPwiuUdKgVu2PzSs?=
 =?us-ascii?Q?Vl4BdugTo92lWYTfj3aIu16CT3xoMG1ZtK+o0UM/L+Hexa5EfphY9FSh3Zr2?=
 =?us-ascii?Q?yQ4ixCwxRPZiBBhslJ9mFxvpyZCKI0Ofi60i54yZpVB0SHcrMuqRNdiPXVmn?=
 =?us-ascii?Q?Ia6VNM+58SRklYOcLz8Xyr2Q/C5XCG6fz974sQYLVHvLitrMDJwoOiSDdBq+?=
 =?us-ascii?Q?UXEa4DfDIuJXAdFU/Uy4xoFtZ9xPDbE1e8AyHXaIpfALtZ6+HF3pW4G+ADq8?=
 =?us-ascii?Q?v6JIn/jcF4LNg3JiVEZ9XVdFlBOsMa6hDSswNuxjJq83/S4yyJwhZdyeJ31O?=
 =?us-ascii?Q?ncHbocLcarXC192iGEM31V4MdZUEcYTrzHXltaiE4xhlJKwZXAUBNJ8mBvZj?=
 =?us-ascii?Q?Hznnfu4sCfTndkaYkNHtglU2KrlBKHiWLs1fMJcBJ88XZ5HdNTteSUSkrlfH?=
 =?us-ascii?Q?V2MS7yByDWJf9Dc4TSPJP27JNKeaiDFLrYjH1M4QmfwbuVK0H2AUQGnOx4lM?=
 =?us-ascii?Q?orY0t6+AqtIFyLyPpDaWflmPqDMvQ9FF0aAFqGc3mlQFPxdfb1JbXpThthTX?=
 =?us-ascii?Q?ALCBlDuPhMjru6yvda8jX6YHylDMtqF9TUMYhlt8dbPXYfn/smP95SgwB0nA?=
 =?us-ascii?Q?eiFb8vJ8q+gcaIOw2Mgc2aokPBXbKW8qwCIzG/47/6RhPmzgsmi35FgEJ2aG?=
 =?us-ascii?Q?+lnJa04UdP8LtXSkLF7QyWySxgeJ9hYt0ro2Tr8LEo9l+bdSMuXucp6cO/0F?=
 =?us-ascii?Q?Atupj9aJUNI6P0W/EFhl9ftng2V/XpRmWzshrJ3ioaV4FuWfgbLU0sYT3vJn?=
 =?us-ascii?Q?n+eXKYXG2vjJ+P2rvrlT+3NlcK+UFGYnyRQgMf8oKD6EQkFKJs8/yNxeb2xB?=
 =?us-ascii?Q?TWiieGBe13iaV7izboPsBcfbCm9eehEzQeh5QYhUIIxvvi74w+ggocvZVxRt?=
 =?us-ascii?Q?IA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3819.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 42f938f7-202b-483d-07eb-08d9fb52fb0b
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2022 07:13:26.6236
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6kNaqfWid9aFuZlJn3bXviki84Z7Qw9oTBIXKmzphbdUkDg4/IeuLHn3yUeZJ84Nifty6CSxzLgzQ74iSdkCNg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2665
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> Subject: [PATCH v3 3/5] fpga: dfl: fix VF creation in OFS

Why this is a fix?=20

>=20
> 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.=20

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),=20
no need to assign/release port for SRIOV enabling.

Hao

>=20
> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
> Signed-off-by: Tianfei zhang <tianfei.zhang@intel.com>
> ---
>  drivers/fpga/dfl.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
>=20
> 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)
>=20
>  	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 !=3D num_vfs) {
> +	if ((cdev->features & DFL_FEAT_PORT_CONNECTED_AFU) &&
> +	    cdev->released_port_num !=3D num_vfs) {
>  		ret =3D -EINVAL;
>  		goto done;
>  	}
> --
> 2.26.2