Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: sjl3Tv2m8m4M3MbkLnyOnL7rG1cQ2aJwc35NGghSAbl0uChN6HtolML2qwUuLtq+TSFSy17B1J
 cMQpk1T2PghQ==
IronPort-SDR: 1kANeuKaO+0oIvx3f59wlBRhWpgrvf1cttPvTPSZuoW75qRncAPP+S/ZiTMMVOxG+Q3KJ42qpY
 xfgyFS9rOAXw==
From:   "Wu, Hao" <hao.wu@intel.com>
To:     "Xu, Yilun" <yilun.xu@intel.com>,
        "matthew.gerlach@linux.intel.com" <matthew.gerlach@linux.intel.com>
CC:     "linux-fpga@vger.kernel.org" <linux-fpga@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "mdf@kernel.org" <mdf@kernel.org>,
        "trix@redhat.com" <trix@redhat.com>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "corbet@lwn.net" <corbet@lwn.net>, "Xu, Yilun" <yilun.xu@intel.com>
Subject: RE: [PATCH 2/2] fpga: dfl: look for vendor specific capability
Thread-Topic: [PATCH 2/2] fpga: dfl: look for vendor specific capability
Thread-Index: AQHWvIBxykoMIcZrHUW2ir3zzcjKk6nL9UsAgAAf7jA=
Date:   Tue, 17 Nov 2020 10:00:22 +0000
Message-ID: <DM6PR11MB381900B67DE65EEBF936CA6885E20@DM6PR11MB3819.namprd11.prod.outlook.com>
References: <20201117012552.262149-1-matthew.gerlach@linux.intel.com>
 <20201117012552.262149-3-matthew.gerlach@linux.intel.com>
 <20201117075626.GA14665@yilunxu-OptiPlex-7050>
In-Reply-To: <20201117075626.GA14665@yilunxu-OptiPlex-7050>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-reaction: no-action
dlp-version: 11.5.1.3
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 61ffc74f-a6cd-4f3b-a6f6-08d88adf9924
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2020 10:00:22.3641
 (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: ozyFfL6E3dmBM7VZXhaKaRToBgnLAhCmUL1k8CYE0peP+oqBoIhjuWN/KI8MAx2D5zgbqp0qzPkC4ji6LT6Evg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1947
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> > +
> > +		start =3D pci_resource_start(pcidev, bar) + offset;
> > +		len -=3D offset;
>=20
> With these code, I have the following assumption:
>=20
> 1. There is only one DFL in one bar, multiple DFLs requires multiple
> bars.
>=20
> 2. The DFL region is from the "offset" to the end of the bar.

I think we should not have such kind of limitation, but at least it=20
requires user clearly from spec, to make sure no overlap case could
happen. We all know that BAR number is small, but we won't limit
DFL numbers by BAR number here.

>=20
> Are they correct? If yes maybe we should specify them clearly in Doc.
>=20
> > +
> > +		if (!PAGE_ALIGNED(start)) {
> > +			dev_err(&pcidev->dev, "%s unaliged start 0x%llx\n",
> > +				__func__, start);
> > +			return -EINVAL;
> > +		}
> > +
> > +		dfl_fpga_enum_info_add_dfl(info, start, len);
>=20
> Do we need some region overlapping check in this func? So we could find
> the HW problem (e.g. same bar num for multiple DFLs) in early stage.

Not sure if VSEC can add a length field for this purpose, otherwise overlap=
ping
check only can be done after enumeration (walk the DFL to know the end).

>=20
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> >  static int find_dfl_in_bar0(struct pci_dev *pcidev,
> >  			    struct dfl_fpga_enum_info *info)
> >  {
> > @@ -221,7 +304,10 @@ static int cci_enumerate_feature_devs(struct
> pci_dev *pcidev)
> >  			goto irq_free_exit;
> >  	}
> >
> > -	ret =3D find_dfl_in_bar0(pcidev, info);
> > +	ret =3D find_dfl_in_cfg(pcidev, info);
> > +
> > +	if (ret)
> > +		ret =3D find_dfl_in_bar0(pcidev, info);
>=20
> The patch is more than the relocation support for DFL. Actually it
> introduced a different way of DFL finding.
>=20
> Previously it starts at bar0 offset 0, find dfl fme first, then find
> dfl port according to fme header registers. Now it enumerates every DFL
> by PCIe VSEC.

Yes, the name is a little confusing, maybe we can rename them.

find_dfls_by_default or find_dfls - to handle original cases.
find_dfls_by_vsec - to handle vsec case.

Thanks
Hao

>=20
> Maybe we should add more description about the change and why.
>=20
> Thanks,
> Yilun
>=20
> >
> >  	if (ret)
> >  		goto irq_free_exit;
> > --
> > 2.25.2