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: O/3BCaxE91i/Yejhg909RfpjaDgJfhMdEgQuLbvRjTdhCDS6m675UJnjsZdyzrB3KP+kVgQBaV
 QssLlJBkaNiQ==
IronPort-SDR: VixqcqpiV0CsGAxMUkf3ODGhz6VQ+Uz2sJ9eGAkGQtN6js7JayAosCGJsa13ag4draVr2t0ezP
 EssV2kVwoqbg==
From:   "Wu, Hao" <hao.wu@intel.com>
To:     "Xu, Yilun" <yilun.xu@intel.com>, Moritz Fischer <mdf@kernel.org>
CC:     "matthew.gerlach@linux.intel.com" <matthew.gerlach@linux.intel.com>,
        "linux-fpga@vger.kernel.org" <linux-fpga@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "trix@redhat.com" <trix@redhat.com>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "corbet@lwn.net" <corbet@lwn.net>
Subject: RE: [PATCH v3 2/2] fpga: dfl: look for vendor specific capability
Thread-Topic: [PATCH v3 2/2] fpga: dfl: look for vendor specific capability
Thread-Index: AQHWwnpOqjhoM37MKU6ujI2Rfo8RvKndD8WwgARhwwCAATDggIAAdlWAgAB6kRA=
Date:   Wed, 2 Dec 2020 09:40:32 +0000
Message-ID: <DM6PR11MB38199A96C6871F1B041694BD85F30@DM6PR11MB3819.namprd11.prod.outlook.com>
References: <20201124155658.700976-1-matthew.gerlach@linux.intel.com>
 <20201124155658.700976-3-matthew.gerlach@linux.intel.com>
 <DM6PR11MB38191D8C5E27E6E04B8DAA1A85F70@DM6PR11MB3819.namprd11.prod.outlook.com>
 <alpine.DEB.2.22.394.2011301614040.1050045@rhweight-WRK1>
 <X8aR36hGoV9SsPDw@archbook> <20201202020003.GB22103@yilunxu-OptiPlex-7050>
In-Reply-To: <20201202020003.GB22103@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: 50dd4967-08c3-4843-011b-08d896a6500c
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2020 09:40:32.3787
 (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: yDwNqpXhODxqkIr2TgfNXEKdngW9pbqFLdQc5HcS7O2o8W5K96dbvxaIxs4nIPscGO05nGkc4itgHpJreooogA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB0073
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> > > >
> > > > > +		}
> > > > > +
> > > > > +		offset =3D dfl_res & PCI_VNDR_DFLS_RES_OFF_MASK;
> > > > > +		if (offset >=3D len) {
> > > > > +			dev_err(&pcidev->dev, "%s bad
> offset %u >=3D %pa\n",
> > > > > +				__func__, offset, &len);
> > > > > +			return -EINVAL;
> > > > > +		}
> > > > > +
> > > > > +		dev_dbg(&pcidev->dev, "%s BAR %d offset 0x%x\n",
> > > > > __func__, bar, offset);
> > > > > +
> > > > > +		len -=3D offset;
> > > > > +
> > > > > +		start =3D pci_resource_start(pcidev, bar) + offset;
> > > > > +
> > > > > +		dfl_fpga_enum_info_add_dfl(info, start, len);
> > > >
> > > > That means everytime, we pass [start, endofbar] region to dfl core
> > > > for enumeration, if there are multiple DFLs in one bar, then each r=
ange
> > > > ends at the same endofbar, it seems fine as enumeration can be done
> > > > one by one, but ideally the best case is that this capability can p=
rovide
> > > > end address or size too, right? It is possible that information can=
 be
> > > > added to the capability as well? then we don't have such limitation=
.
> > > >
> > > > Hao
> > >
> > > I am not sure having more than one DFL in a bar serves any purpose ov=
er
> a
> > > single DFL.  Regardless, I think the consistency of just having Offse=
t/BIR
> > > in the VSEC is better than adding more infomation that has little or =
no
> > > added value.
> >
> > Agreed. Can't you just link the DFLs in that case?
>=20
> I didn't see the value of more DFLs in one bar either. So I think we'd be=
tter
> document it.

Yes, it needs to be documented well, otherwise users may have their own
choices, e.g. link 100 queues together by modify DFH registers of the
queues one by one, or just have them done together in the VSEC. I am not
sure which one is the easier way for logic developer, but at least we need =
to
document what driver can support.=20

Thanks
Hao

>=20
> Thanks,
> Yilun