From: Xu Yilun <yilun.xu@intel.com>
To: Moritz Fischer <mdf@kernel.org>
Cc: matthew.gerlach@linux.intel.com, "Wu, Hao" <hao.wu@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
Date: Wed, 2 Dec 2020 10:00:03 +0800 [thread overview]
Message-ID: <20201202020003.GB22103@yilunxu-OptiPlex-7050> (raw)
In-Reply-To: <X8aR36hGoV9SsPDw@archbook>
> > >
> > > > + }
> > > > +
> > > > + offset = dfl_res & PCI_VNDR_DFLS_RES_OFF_MASK;
> > > > + if (offset >= len) {
> > > > + dev_err(&pcidev->dev, "%s bad offset %u >= %pa\n",
> > > > + __func__, offset, &len);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + dev_dbg(&pcidev->dev, "%s BAR %d offset 0x%x\n",
> > > > __func__, bar, offset);
> > > > +
> > > > + len -= offset;
> > > > +
> > > > + start = 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 range
> > > 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 provide
> > > 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 over a
> > single DFL. Regardless, I think the consistency of just having Offset/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?
I didn't see the value of more DFLs in one bar either. So I think we'd better
document it.
Thanks,
Yilun
next prev parent reply other threads:[~2020-12-02 2:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-24 15:56 [PATCH v3 0/2] fpga: dfl: optional VSEC for start of dfl matthew.gerlach
2020-11-24 15:56 ` [PATCH v3 1/2] fpga: dfl: refactor cci_enumerate_feature_devs() matthew.gerlach
[not found] ` <DM6PR11MB3819B8E32400D0662CFAD20685F70@DM6PR11MB3819.namprd11.prod.outlook.com>
2020-11-30 23:48 ` matthew.gerlach
2020-11-24 15:56 ` [PATCH v3 2/2] fpga: dfl: look for vendor specific capability matthew.gerlach
[not found] ` <DM6PR11MB38191D8C5E27E6E04B8DAA1A85F70@DM6PR11MB3819.namprd11.prod.outlook.com>
2020-12-01 0:45 ` matthew.gerlach
2020-12-01 18:56 ` Moritz Fischer
2020-12-02 2:00 ` Xu Yilun [this message]
2020-12-02 9:40 ` Wu, Hao
2020-12-02 19:17 ` matthew.gerlach
2020-12-02 9:56 ` Wu, Hao
2020-12-02 19:06 ` matthew.gerlach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201202020003.GB22103@yilunxu-OptiPlex-7050 \
--to=yilun.xu@intel.com \
--cc=corbet@lwn.net \
--cc=hao.wu@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.gerlach@linux.intel.com \
--cc=mdf@kernel.org \
--cc=trix@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox