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: wbn+5yo2l6S8Y75RZSo6elGDSmpAph7lldN6mldgsUoNZOvKqTSwcg1WpAj9c2eCyWJbfsYyqq
 s9K2sZ05RzbQ==
IronPort-SDR: WRuwfisFSEEiOt8jq1p1m8Z0fSCjGEh3qBAHm+NTa4mbKgfnHv/rO7NxRHXeV2MUmx8gd6hlwB
 QFC0vFvY7w9A==
Date:   Wed, 2 Dec 2020 10:00:03 +0800
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
Message-ID: <20201202020003.GB22103@yilunxu-OptiPlex-7050>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <X8aR36hGoV9SsPDw@archbook>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk

> > > 
> > > > +		}
> > > > +
> > > > +		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