Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp2304833pxb; Sat, 21 Nov 2020 17:23:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJwLaKvohIMUuvKGWsXYIv/hlhnBhjgshp5PoTpHSIpcVmmku1sFFDKikyaSubPSytu09Mtb X-Received: by 2002:a05:6402:16d6:: with SMTP id r22mr42661987edx.246.1606008231917; Sat, 21 Nov 2020 17:23:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606008231; cv=none; d=google.com; s=arc-20160816; b=RoFS7Krz/ZPYQJeYWuhf6JQjZ4CTmtbt9c1kyTzY6H8HR8PbuPJEfswthgHDaDUZZp RReckSi6aeez6KZFzmKVjTZMaVwNl9F9hfApzSii4djm8zvuUPMC+7HxFgziUfNijXqn v4TuLFtTVTIrcXEuC/8tA1FDOr1yf1xvQXlG/l7CpVSeFXsRddbgNX3hm6XOfvoZzMP6 3C6qlT520+ITLNqQeEnR5povDEb9m55CANbG0LIF8Hs9TJJqfpc7uE08REAcyNj8iID+ BznWzVlN3h5Dbh6vVp6OgBsJ/v8GW2YxOlf9CsJBzTmeELGXPlhCoihPUHzTZE9zVMmA 2WKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=6F+q0z8uoO6RqleJlDf5TYXGbSMvGrDWob+nbFawBEo=; b=Ecfguq+UWglHgG5V/neW4moWoagfXzTA0RREbo8DU7c66XefU7zUSquA06vDxX3G37 qwfgMKrNpAuUDCxj8svobQzQGe/oFrK4c5E6qF3x6iQ1Ssr4+P1YRFM7qptA6FrHL8au A4EatIrgJRGOXkKv5Eaarb5C8oBJiogohVxQUTpemwpfH6ULTLkVl3TW738VXaEg/M+Y 57ZOBntlZN8Du6h3efCOKyYRNk+lgZJiUEFiBe9RtQaiwT25200VyFV3c5CK1j3P4Q0d PphX/3w21oIsGLswTvgeWqiVBdLoz1xvo3lCTNmjZHpAqAyshJ1OvubL+ub9tMBAGyKD /M1w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q26si4442198edi.57.2020.11.21.17.23.26; Sat, 21 Nov 2020 17:23:51 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726983AbgKVBS6 (ORCPT + 99 others); Sat, 21 Nov 2020 20:18:58 -0500 Received: from mail-pf1-f196.google.com ([209.85.210.196]:37746 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726431AbgKVBS5 (ORCPT ); Sat, 21 Nov 2020 20:18:57 -0500 Received: by mail-pf1-f196.google.com with SMTP id c66so11556622pfa.4; Sat, 21 Nov 2020 17:18:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=6F+q0z8uoO6RqleJlDf5TYXGbSMvGrDWob+nbFawBEo=; b=g5B16rLfqCoMeFMwBOi46BdKBWmN8TG7XQiGFxguaPzCZZTxsyGsvNwNp1Bck2vNm1 kkXyle2UWEsu+iIYbipG5ey68kB3O0YP/yhvukVdMtRHlsw3tnc2Uqy0Zj5Qo7a0XeDV ho/6JcncaVmMqVgHk1/xsX7Vu3AgeS1v1Tht3AMgE5SrJtrWH3Cd3GhJvsSqx6OM8b+Z GvROeG3h3YjmFiJWuSazSzzzyMwM/CoEVmUtnZlDT/ecIDBB+21VD1P/UzYk4DwFZroB jGM63acyn376ZBUyeRMSNohxu49PGiRIIH6kbMMMr7sy1nK2MC4UiGkZENeAf7l9TA5q 0doQ== X-Gm-Message-State: AOAM533AiSoTRmyUs0uhH2smFbitqNlVEur3DDJWC1Ai0p/N85Rtr4Sd 6KehJ7QJwAlqLeC8H7uLaSw= X-Received: by 2002:a62:a11a:0:b029:18a:df9e:f537 with SMTP id b26-20020a62a11a0000b029018adf9ef537mr19083044pff.29.1606007936315; Sat, 21 Nov 2020 17:18:56 -0800 (PST) Received: from localhost (c-73-235-149-126.hsd1.ca.comcast.net. [73.235.149.126]) by smtp.gmail.com with ESMTPSA id v63sm7794669pfb.217.2020.11.21.17.18.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 21 Nov 2020 17:18:55 -0800 (PST) Date: Sat, 21 Nov 2020 17:18:54 -0800 From: Moritz Fischer To: matthew.gerlach@linux.intel.com Cc: linux-fpga@vger.kernel.org, linux-kernel@vger.kernel.org, mdf@kernel.org, hao.wu@intel.com, trix@redhat.com, linux-doc@vger.kernel.org, corbet@lwn.net Subject: Re: [PATCH v2 2/2] fpga: dfl: look for vendor specific capability Message-ID: References: <20201118190151.365564-1-matthew.gerlach@linux.intel.com> <20201118190151.365564-3-matthew.gerlach@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201118190151.365564-3-matthew.gerlach@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Matthew, On Wed, Nov 18, 2020 at 11:01:51AM -0800, matthew.gerlach@linux.intel.com wrote: > From: Matthew Gerlach > > A DFL may not begin at offset 0 of BAR 0. A PCIe vendor > specific capability can be used to specify the start of a > number of DFLs. > > Signed-off-by: Matthew Gerlach > --- > v2: Update documentation for clarity. > Clean up macro names. > Use GENMASK. > Removed spurious blank lines. > Changed some calls from dev_info to dev_dbg. > Specifically check for VSEC not found, -ENODEV. > Ensure correct pci vendor id. > Remove check for page alignment. > Rename find_dfl_in_cfg to find_dfls_by_vsec. > Initialize target memory of pci_read_config_dword to invalid values before use. > --- > Documentation/fpga/dfl.rst | 13 ++++++ > drivers/fpga/dfl-pci.c | 87 +++++++++++++++++++++++++++++++++++++- > 2 files changed, 98 insertions(+), 2 deletions(-) > > diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst > index 0404fe6ffc74..37016ff35a90 100644 > --- a/Documentation/fpga/dfl.rst > +++ b/Documentation/fpga/dfl.rst > @@ -501,6 +501,19 @@ Developer only needs to provide a sub feature driver with matched feature id. > FME Partial Reconfiguration Sub Feature driver (see drivers/fpga/dfl-fme-pr.c) > could be a reference. > > +Location of DFLs on PCI Device > +=========================== Maybe start with: "There are two ways of locating the DFLs" > +The start of the first DFL is assumed to be offset 0 of bar 0. > +If the first node of the DFL is an FME, then further DFLs > +in the port(s) are specified in FME header registers. > +Alternatively, a vendor specific capability structure can be used to > +specify the location of all the DFLs on the device, providing flexibility > +for the type of starting node in the DFL. Intel has reserved the > +VSEC ID of 0x43 for this purpose. The vendor specific > +data begins with a 4 byte vendor specific register for the number of DFLs followed 4 byte > +Offset/BIR vendor specific registers for each DFL. Bits 2:0 of Offset/BIR register > +indicates the BAR, and bits 31:3 form the 8 byte aligned offset where bits 2:0 are > +zero. It's nice to have details, thanks! Nit: This could be a table maybe? > > Open discussion > =============== > diff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl-pci.c > index b27fae045536..3a6807e3e10c 100644 > --- a/drivers/fpga/dfl-pci.c > +++ b/drivers/fpga/dfl-pci.c > @@ -27,6 +27,14 @@ > #define DRV_VERSION "0.8" > #define DRV_NAME "dfl-pci" > > +#define PCI_VSEC_ID_INTEL_DFLS 0x43 > + > +#define PCI_VNDR_DFLS_CNT 8 > +#define PCI_VNDR_DFLS_RES 0x0c > + > +#define PCI_VNDR_DFLS_RES_BAR_MASK GENMASK(2, 0) > +#define PCI_VNDR_DFLS_RES_OFF_MASK GENMASK(31, 3) > + > struct cci_drvdata { > struct dfl_fpga_cdev *cdev; /* container device */ > }; > @@ -119,8 +127,80 @@ static int *cci_pci_create_irq_table(struct pci_dev *pcidev, unsigned int nvec) > return table; > } > > +static int find_dfls_by_vsec(struct pci_dev *pcidev, struct dfl_fpga_enum_info *info) > +{ > + u32 bar, offset, vndr_hdr, dfl_cnt, dfl_res; > + int dfl_res_off, i, voff = 0; > + resource_size_t start, len; > + > + if (pcidev->vendor != PCI_VENDOR_ID_INTEL) > + return -ENODEV; > + > + while ((voff = pci_find_next_ext_capability(pcidev, voff, PCI_EXT_CAP_ID_VNDR))) { > + vndr_hdr = 0; > + pci_read_config_dword(pcidev, voff + PCI_VNDR_HEADER, &vndr_hdr); Are there concerns around those failing? > + > + dev_dbg(&pcidev->dev, > + "vendor-specific capability id 0x%x, rev 0x%x len 0x%x\n", > + PCI_VNDR_HEADER_ID(vndr_hdr), > + PCI_VNDR_HEADER_REV(vndr_hdr), > + PCI_VNDR_HEADER_LEN(vndr_hdr)); > + > + if (PCI_VNDR_HEADER_ID(vndr_hdr) == PCI_VSEC_ID_INTEL_DFLS) > + break; > + } > + > + if (!voff) { > + dev_dbg(&pcidev->dev, "%s no VSEC found\n", __func__); > + return -ENODEV; > + } > + > + dfl_cnt = 0; > + pci_read_config_dword(pcidev, voff + PCI_VNDR_DFLS_CNT, &dfl_cnt); I guess this could fall on it's face if you'd read back ~0 ... maybe I'm being too paranoid :) > + dev_dbg(&pcidev->dev, "dfl_cnt %d\n", dfl_cnt); > + for (i = 0; i < dfl_cnt; i++) { > + dfl_res_off = voff + PCI_VNDR_DFLS_RES + > + (i * sizeof(dfl_res)); > + dfl_res = GENMASK(31, 0); > + pci_read_config_dword(pcidev, dfl_res_off, &dfl_res); > + > + dev_dbg(&pcidev->dev, "dfl_res 0x%x\n", dfl_res); > + > + bar = dfl_res & PCI_VNDR_DFLS_RES_BAR_MASK; > + if (bar >= PCI_STD_NUM_BARS) { > + dev_err(&pcidev->dev, "%s bad bar number %d\n", > + __func__, bar); > + return -EINVAL; > + } > + > + len = pci_resource_len(pcidev, bar); > + if (len == 0) { > + dev_err(&pcidev->dev, "%s unmapped bar number %d\n", > + __func__, bar); > + return -EINVAL; > + } > + > + 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); > + } > + > + return 0; > +} > + > static int find_dfls_by_default(struct pci_dev *pcidev, > - struct dfl_fpga_enum_info *info) > + struct dfl_fpga_enum_info *info) > { > resource_size_t start, len; > int port_num, bar, i; > @@ -220,7 +300,10 @@ static int cci_enumerate_feature_devs(struct pci_dev *pcidev) > goto irq_free_exit; > } > > - ret = find_dfls_by_default(pcidev, info); > + ret = find_dfls_by_vsec(pcidev, info); > + if (ret == -ENODEV) > + ret = find_dfls_by_default(pcidev, info); > + > if (ret) > goto irq_free_exit; > > -- > 2.25.2 > Thanks, Moritz