From: Ben Widawsky <hidden> Date: 2021-09-23 17:30:34
Changes since v1 [3]:
- get_max_afu_index() updated to new interface (Dan)
- siov_find_pci_dvsec updated to new interface (Dan)
- remove unnecessary pci request/release regions with refactor (Dan)
- move @base into cxl_register_map (Dan)
- Expanded the Cc list to include other users of PCIe DVSEC. (Dan)
Three spots are not converted to use the new PCI core DVSEC helper as the
changes are non-trivial.
- find_dvsec_afu_ctrl (ocxl)
- pmt_pci_probe (David)
- intel_uncore_has_discovery_tables (Kan)
The interdiff is below. A range-diff can be generated against v1[3] if desired.
Discussion occurred partially offlist between Dan and myself. To summarize, Dan
contends that patch 4, "cxl/pci: Refactor cxl_pci_setup_regs" should either be
rewrittn, or have a precursor patch that cxl_pci will still scan all register
blocks, but only claim the specified types. While the current diff is somewhat
complex, I contend that this is unneeded churn because we can easily test this
change in our existing regression testing. It also ultimately results in a
simpler function in the cxl_port patch series when cxl_pci stops trying to map
the component register block (loop is removed entirely). A tiebreak here would
be great :-)
---
Original commit message:
Provide the ability to obtain CXL register blocks as discrete functionality.
This functionality will become useful for other CXL drivers that need access to
CXL register blocks. It is also in line with other additions to core which moves
register mapping functionality.
At the introduction of the CXL driver the only user of CXL MMIO was cxl_pci
(then known as cxl_mem). As the driver has evolved it is clear that cxl_pci will
not be the only entity that needs access to CXL MMIO. This series stops short of
moving the generalized functionality into cxl_core for the sake of getting eyes
on the important foundational bits sooner rather than later. The ultimate plan
is to move much of the code into cxl_core.
Via review of two previous patches [1] & [2] it has been suggested that the bits
which are being used for DVSEC enumeration move into PCI core. As CXL core is
soon going to require these, let's try to get the ball rolling now on making
that happen.
---
[1]: https://lore.kernel.org/linux-pci/20210913190131.xiiszmno46qie7v5@intel.com/
[2]: https://lore.kernel.org/linux-cxl/20210920225638.1729482-1-ben.widawsky@intel.com/
[3]: https://lore.kernel.org/linux-cxl/20210921220459.2437386-1-ben.widawsky@intel.com/
Ben Widawsky (9):
cxl: Convert "RBI" to enum
cxl/pci: Remove dev_dbg for unknown register blocks
cxl/pci: Remove pci request/release regions
cxl/pci: Refactor cxl_pci_setup_regs
cxl/pci: Make more use of cxl_register_map
PCI: Add pci_find_dvsec_capability to find designated VSEC
cxl/pci: Use pci core's DVSEC functionality
ocxl: Use pci core's DVSEC functionality
iommu/vt-d: Use pci core's DVSEC functionality
arch/powerpc/platforms/powernv/ocxl.c | 3 +-
drivers/cxl/cxl.h | 1 +
drivers/cxl/pci.c | 176 ++++++++++++--------------
drivers/cxl/pci.h | 14 +-
drivers/iommu/intel/iommu.c | 15 +--
drivers/misc/ocxl/config.c | 13 +-
drivers/pci/pci.c | 32 +++++
include/linux/pci.h | 1 +
8 files changed, 127 insertions(+), 128 deletions(-)
Interdiff against v1:
From: Ben Widawsky <hidden> Date: 2021-09-23 17:30:59
In preparation for passing around the Register Block Indicator (RBI) as
a parameter, it is desirable to convert the type to an enum so that the
interface can use a well defined type checked parameter.
As a result of this change, should future versions of the spec add
sparsely defined identifiers, it could become a problem if checking for
invalid identifiers since the code currently checks for the max
identifier. This is not an issue with current spec, and the algorithm to
obtain the register blocks will change before those possible additions
are made.
Signed-off-by: Ben Widawsky <redacted>
---
drivers/cxl/pci.h | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
From: Ben Widawsky <hidden> Date: 2021-09-23 17:31:22
While interesting to driver developers, the dev_dbg message doesn't do
much except clutter up logs. This information should be attainable
through sysfs, and someday lspci like utilities. This change
additionally helps reduce the LOC in a subsequent patch to refactor some
of cxl_pci register mapping.
Signed-off-by: Ben Widawsky <redacted>
---
drivers/cxl/pci.c | 3 ---
1 file changed, 3 deletions(-)
@@ -475,9 +475,6 @@ static int cxl_pci_setup_regs(struct cxl_mem *cxlm)cxl_decode_register_block(reg_lo,reg_hi,&bar,&offset,®_type);-dev_dbg(dev,"Found register block in bar %u @ 0x%llx of type %u\n",-bar,offset,reg_type);-/* Ignore unknown register block types */if(reg_type>CXL_REGLOC_RBI_MEMDEV)continue;
From: Ben Widawsky <hidden> Date: 2021-09-23 17:31:45
Quoting Dan, "... the request + release regions should probably just be
dropped. It's not like any of the register enumeration would collide
with someone else who already has the registers mapped. The collision
only comes when the registers are mapped for their final usage, and that
will have more precision in the request."
Recommended-by: Dan Williams [off-list ref]
Signed-off-by: Ben Widawsky <redacted>
---
drivers/cxl/pci.c | 5 -----
1 file changed, 5 deletions(-)
@@ -453,9 +453,6 @@ static int cxl_pci_setup_regs(struct cxl_mem *cxlm)return-ENXIO;}-if(pci_request_mem_regions(pdev,pci_name(pdev)))-return-ENODEV;-/* Get the size of the Register Locator DVSEC */pci_read_config_dword(pdev,regloc+PCI_DVSEC_HEADER1,®loc_size);regloc_size=FIELD_GET(PCI_DVSEC_HEADER1_LENGTH_MASK,regloc_size);
@@ -499,8 +496,6 @@ static int cxl_pci_setup_regs(struct cxl_mem *cxlm)n_maps++;}-pci_release_mem_regions(pdev);-for(i=0;i<n_maps;i++){ret=cxl_map_regs(cxlm,&maps[i]);if(ret)
From: Ben Widawsky <hidden> Date: 2021-09-23 17:32:08
In preparation for moving parts of register mapping to cxl_core, the
cxl_pci driver is refactored to utilize a new helper to find register
blocks by type.
cxl_pci scanned through all register blocks and mapping the ones that
the driver will use. This logic is inverted so that the driver
specifically requests the register blocks from a new helper. Under the
hood, the same implementation of scanning through all register locator
DVSEC entries exists.
There are 2 behavioral changes (#2 is arguable):
1. A dev_err is introduced if cxl_map_regs fails.
2. The previous logic would try to map component registers and device
registers multiple times if there were present and keep the mapping
of the last one found (furthest offset in the register locator).
While this is disallowed in the spec, CXL 2.0 8.1.9: "Each register
block identifier shall only occur once in the Register Locator DVSEC
structure" it was how the driver would respond to the spec violation.
The new logic will take the first found register block by type and
move on.
Signed-off-by: Ben Widawsky <redacted>
---
Changes since v1:
---
drivers/cxl/pci.c | 126 +++++++++++++++++++++++++---------------------
1 file changed, 70 insertions(+), 56 deletions(-)
From: Ben Widawsky <hidden> Date: 2021-09-23 17:32:31
The structure exists to pass around information about register mapping.
Using it more extensively cleans up many existing functions.
Signed-off-by: Ben Widawsky <redacted>
---
drivers/cxl/cxl.h | 1 +
drivers/cxl/pci.c | 36 +++++++++++++++++-------------------
2 files changed, 18 insertions(+), 19 deletions(-)
@@ -306,35 +306,36 @@ static int cxl_pci_setup_mailbox(struct cxl_mem *cxlm)return0;}-staticvoid__iomem*cxl_pci_map_regblock(structcxl_mem*cxlm,-u8bar,u64offset)+staticintcxl_pci_map_regblock(structcxl_mem*cxlm,structcxl_register_map*map){-void__iomem*addr;+intbar=map->barno;structdevice*dev=cxlm->dev;structpci_dev*pdev=to_pci_dev(dev);+resource_size_toffset=map->block_offset;/* Basic sanity check that BAR is big enough */if(pci_resource_len(pdev,bar)<offset){dev_err(dev,"BAR%d: %pr: too small (offset: %#llx)\n",bar,&pdev->resource[bar],(unsignedlonglong)offset);-returnIOMEM_ERR_PTR(-ENXIO);+return-ENXIO;}-addr=pci_iomap(pdev,bar,0);-if(!addr){+map->base=pci_iomap(pdev,bar,0);+if(!map->base){dev_err(dev,"failed to map registers\n");-returnaddr;+returnPTR_ERR(map->base);}dev_dbg(dev,"Mapped CXL Memory Device resource bar %u @ %#llx\n",bar,offset);-returnaddr;+return0;}-staticvoidcxl_pci_unmap_regblock(structcxl_mem*cxlm,void__iomem*base)+staticvoidcxl_pci_unmap_regblock(structcxl_mem*cxlm,structcxl_register_map*map){-pci_iounmap(to_pci_dev(cxlm->dev),base);+pci_iounmap(to_pci_dev(cxlm->dev),map->base);+map->base=0;}staticintcxl_pci_dvsec(structpci_dev*pdev,intdvsec)
@@ -360,9 +361,9 @@ static int cxl_pci_dvsec(struct pci_dev *pdev, int dvsec)return0;}-staticintcxl_probe_regs(structcxl_mem*cxlm,void__iomem*base,-structcxl_register_map*map)+staticintcxl_probe_regs(structcxl_mem*cxlm,structcxl_register_map*map){+void__iomem*base=map->base+map->block_offset;structcxl_component_reg_map*comp_map;structcxl_device_reg_map*dev_map;structdevice*dev=cxlm->dev;
@@ -487,7 +488,6 @@ static int cxl_pci_setup_regs(struct cxl_mem *cxlm)for(i=0;i<ARRAY_SIZE(types);i++){structcxl_register_mapmap;-void__iomem*base;rc=find_register_block(pdev,types[i],&map);if(rc){
@@ -498,14 +498,12 @@ static int cxl_pci_setup_regs(struct cxl_mem *cxlm)break;}-base=cxl_pci_map_regblock(cxlm,map.barno,map.block_offset);-if(!base){-rc=-ENOMEM;+rc=cxl_pci_map_regblock(cxlm,&map);+if(rc)break;-}-rc=cxl_probe_regs(cxlm,base+map.block_offset,&map);-cxl_pci_unmap_regblock(cxlm,base);+rc=cxl_probe_regs(cxlm,&map);+cxl_pci_unmap_regblock(cxlm,&map);if(rc)break;
From: Ben Widawsky <hidden> Date: 2021-09-23 17:32:54
Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
Extended Capability with the specified DVSEC ID.
The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
more vendor specific capabilities that aren't tied to the vendor ID of
the PCI component.
DVSEC is critical for both the Compute Express Link (CXL) driver as well
as the driver for OpenCAPI coherent accelerator (OCXL).
Cc: David E. Box <david.e.box@linux.intel.com>
Cc: Jonathan Cameron <redacted>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Dan Williams <redacted>
Cc: linux-pci@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Andrew Donnellan <redacted>
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Frederic Barrat <redacted>
Signed-off-by: Ben Widawsky <redacted>
---
drivers/pci/pci.c | 32 ++++++++++++++++++++++++++++++++
include/linux/pci.h | 1 +
2 files changed, 33 insertions(+)
From: Ben Widawsky <hidden> Date: 2021-09-23 17:33:42
Reduce maintenance burden of DVSEC query implementation by using the
centralized PCI core implementation.
There are two obvious places to simply drop in the new core
implementation. There remains find_dvsec_from_pos() which would benefit
from using a core implementation. As that change is less trivial it is
reserved for later.
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Andrew Donnellan <redacted>
Acked-by: Frederic Barrat <redacted> (v1)
Signed-off-by: Ben Widawsky <redacted>
---
arch/powerpc/platforms/powernv/ocxl.c | 3 ++-
drivers/misc/ocxl/config.c | 13 +------------
2 files changed, 3 insertions(+), 13 deletions(-)
From: Liang, Kan <hidden> Date: 2021-09-23 21:38:56
On 9/23/2021 1:26 PM, Ben Widawsky wrote:
Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
Extended Capability with the specified DVSEC ID.
The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
more vendor specific capabilities that aren't tied to the vendor ID of
the PCI component.
DVSEC is critical for both the Compute Express Link (CXL) driver as well
as the driver for OpenCAPI coherent accelerator (OCXL).
Cc: David E. Box <david.e.box@linux.intel.com>
Cc: Jonathan Cameron <redacted>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Dan Williams <redacted>
Cc: linux-pci@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Andrew Donnellan <redacted>
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Frederic Barrat <redacted>
Signed-off-by: Ben Widawsky <redacted>
Applied the interface for the perf uncore driver as below. The interface
works properly.
Tested-by: Kan Liang <redacted>
From ebb69ba386dca91fb372522b13af9feb84adcbc0 Mon Sep 17 00:00:00 2001
From: Kan Liang <redacted>
Date: Thu, 23 Sep 2021 13:59:24 -0700
Subject: [PATCH] perf/x86/intel/uncore: Use pci core's DVSEC functionality
Apply standard interface pci_find_dvsec_capability for perf uncore
driver and remove unused macros.
Reduce maintenance burden of DVSEC query implementation.
Signed-off-by: Kan Liang <redacted>
---
arch/x86/events/intel/uncore_discovery.c | 41
+++++++++++++++-----------------
arch/x86/events/intel/uncore_discovery.h | 6 -----
2 files changed, 19 insertions(+), 28 deletions(-)
@@ -2,12 +2,6 @@/* Generic device ID of a discovery table device */#define UNCORE_DISCOVERY_TABLE_DEVICE 0x09a7-/* Capability ID for a discovery table device */-#define UNCORE_EXT_CAP_ID_DISCOVERY 0x23-/* First DVSEC offset */-#define UNCORE_DISCOVERY_DVSEC_OFFSET 0x8-/* Mask of the supported discovery entry type */-#define UNCORE_DISCOVERY_DVSEC_ID_MASK 0xffff/* PMON discovery entry type ID */#define UNCORE_DISCOVERY_DVSEC_ID_PMON 0x1/* Second DVSEC offset */
--
2.7.4
Thanks,
Kan
> ---
> drivers/pci/pci.c | 32 ++++++++++++++++++++++++++++++++
> include/linux/pci.h | 1 +
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index ce2ab62b64cf..94ac86ff28b0 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -732,6 +732,38 @@ u16 pci_find_vsec_capability(struct pci_dev *dev, u16 vendor, int cap)
> }
> EXPORT_SYMBOL_GPL(pci_find_vsec_capability);
>
> +/**
> + * pci_find_dvsec_capability - Find DVSEC for vendor
> + * @dev: PCI device to query
> + * @vendor: Vendor ID to match for the DVSEC
> + * @dvsec: Designated Vendor-specific capability ID
> + *
> + * If DVSEC has Vendor ID @vendor and DVSEC ID @dvsec return the capability
> + * offset in config space; otherwise return 0.
> + */
> +u16 pci_find_dvsec_capability(struct pci_dev *dev, u16 vendor, u16 dvsec)
> +{
> + int pos;
> +
> + pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DVSEC);
> + if (!pos)
> + return 0;
> +
> + while (pos) {
> + u16 v, id;
> +
> + pci_read_config_word(dev, pos + PCI_DVSEC_HEADER1, &v);
> + pci_read_config_word(dev, pos + PCI_DVSEC_HEADER2, &id);
> + if (vendor == v && dvsec == id)
> + return pos;
> +
> + pos = pci_find_next_ext_capability(dev, pos, PCI_EXT_CAP_ID_DVSEC);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_find_dvsec_capability);
> +
> /**
> * pci_find_parent_resource - return resource region of parent bus of given
> * region
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index cd8aa6fce204..c93ccfa4571b 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1130,6 +1130,7 @@ u16 pci_find_ext_capability(struct pci_dev *dev, int cap);
> u16 pci_find_next_ext_capability(struct pci_dev *dev, u16 pos, int cap);
> struct pci_bus *pci_find_next_bus(const struct pci_bus *from);
> u16 pci_find_vsec_capability(struct pci_dev *dev, u16 vendor, int cap);
> +u16 pci_find_dvsec_capability(struct pci_dev *dev, u16 vendor, u16 dvsec);
>
> u64 pci_get_dsn(struct pci_dev *dev);
>
>
I hink the siov_find_pci_dvsec helper is pretty pointless now and can be
folded into its only caller. And independent of that: this capability
really needs a symbolic name. Especially for a vendor like Intel that
might have a few there should be a list of them somewhere.
s/pci_find_dvsec_capability/pci_find_dvsec_capability()/ in subject
and commit log.
On Thu, Sep 23, 2021 at 10:26:44AM -0700, Ben Widawsky wrote:
Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
Extended Capability with the specified DVSEC ID.
"specified Vendor ID and Capability ID".
The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
more vendor specific capabilities that aren't tied to the vendor ID of
the PCI component.
DVSEC is critical for both the Compute Express Link (CXL) driver as well
as the driver for OpenCAPI coherent accelerator (OCXL).
Strictly speaking, not really relevant for the commit log.
Cc: David E. Box <david.e.box@linux.intel.com>
Cc: Jonathan Cameron <redacted>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Dan Williams <redacted>
Cc: linux-pci@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Andrew Donnellan <redacted>
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Frederic Barrat <redacted>
Signed-off-by: Ben Widawsky <redacted>
If you want to merge this with the series,
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Or if you want me to merge this on a branch, let me know.
From: Dan Williams <hidden> Date: 2021-09-27 23:14:43
Please spell out "register block indicator" in the subject so that the
shortlog remains somewhat readable.
On Thu, Sep 23, 2021 at 10:27 AM Ben Widawsky [off-list ref] wrote:
In preparation for passing around the Register Block Indicator (RBI) as
a parameter, it is desirable to convert the type to an enum so that the
interface can use a well defined type checked parameter.
C wouldn't type check this unless it failed an integer conversion,
right? It would need to be a struct to get useful type checking.
I don't mind this for the self documenting properties it has for the
functions that will take this as a parameter, but maybe clarify what
you mean by type checked parameter?
As a result of this change, should future versions of the spec add
sparsely defined identifiers, it could become a problem if checking for
invalid identifiers since the code currently checks for the max
identifier. This is not an issue with current spec, and the algorithm to
obtain the register blocks will change before those possible additions
are made.
In general let's not spend changelog space trying to guess what future
specs may or may not do. I.e. I think this text can be dropped,
especially because enums can support sparse number spaces.
From: Andrew Donnellan <hidden> Date: 2021-09-28 05:51:36
On 24/9/21 3:26 am, Ben Widawsky wrote:
Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
Extended Capability with the specified DVSEC ID.
The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
more vendor specific capabilities that aren't tied to the vendor ID of
the PCI component.
DVSEC is critical for both the Compute Express Link (CXL) driver as well
as the driver for OpenCAPI coherent accelerator (OCXL).
Cc: David E. Box <david.e.box@linux.intel.com>
Cc: Jonathan Cameron <redacted>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Dan Williams <redacted>
Cc: linux-pci@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Andrew Donnellan <redacted>
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Frederic Barrat <redacted>
Signed-off-by: Ben Widawsky <redacted>
Looks good to me, it's essentially identical to the existing
implementation in ocxl.
Reviewed-by: Andrew Donnellan <redacted>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
From: Andrew Donnellan <hidden> Date: 2021-09-28 05:53:36
On 24/9/21 3:26 am, Ben Widawsky wrote:
Reduce maintenance burden of DVSEC query implementation by using the
centralized PCI core implementation.
There are two obvious places to simply drop in the new core
implementation. There remains find_dvsec_from_pos() which would benefit
from using a core implementation. As that change is less trivial it is
reserved for later.
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Andrew Donnellan <redacted>
Acked-by: Frederic Barrat <redacted> (v1)
Signed-off-by: Ben Widawsky <redacted>
Looks fine, but we should clean up find_dvsec_from_pos() afterwards.
Reviewed-by: Andrew Donnellan <redacted>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
From: Dan Williams <hidden> Date: 2021-09-28 14:39:04
On Thu, Sep 23, 2021 at 10:27 AM Ben Widawsky [off-list ref] wrote:
While interesting to driver developers, the dev_dbg message doesn't do
much except clutter up logs. This information should be attainable
through sysfs, and someday lspci like utilities. This change
additionally helps reduce the LOC in a subsequent patch to refactor some
of cxl_pci register mapping.
Looks good to me:
Reviewed-by: Dan Williams <redacted>
From: Dan Williams <hidden> Date: 2021-09-28 14:42:55
On Thu, Sep 23, 2021 at 10:26 AM Ben Widawsky [off-list ref] wrote:
Quoting Dan, "... the request + release regions should probably just be
dropped. It's not like any of the register enumeration would collide
with someone else who already has the registers mapped. The collision
only comes when the registers are mapped for their final usage, and that
will have more precision in the request."
Looks good to me:
Reviewed-by: Dan Williams <redacted>
Recommended-by: Dan Williams [off-list ref]
This isn't one of the canonical tags:
Documentation/process/submitting-patches.rst
I'll change this to Suggested-by:
@@ -453,9 +453,6 @@ static int cxl_pci_setup_regs(struct cxl_mem *cxlm)return-ENXIO;}-if(pci_request_mem_regions(pdev,pci_name(pdev)))-return-ENODEV;-/* Get the size of the Register Locator DVSEC */pci_read_config_dword(pdev,regloc+PCI_DVSEC_HEADER1,®loc_size);regloc_size=FIELD_GET(PCI_DVSEC_HEADER1_LENGTH_MASK,regloc_size);
@@ -499,8 +496,6 @@ static int cxl_pci_setup_regs(struct cxl_mem *cxlm)n_maps++;}-pci_release_mem_regions(pdev);-for(i=0;i<n_maps;i++){ret=cxl_map_regs(cxlm,&maps[i]);if(ret)--
From: Dan Williams <hidden> Date: 2021-09-28 17:36:35
On Thu, Sep 23, 2021 at 10:27 AM Ben Widawsky [off-list ref] wrote:
In preparation for moving parts of register mapping to cxl_core, the
cxl_pci driver is refactored to utilize a new helper to find register
blocks by type.
cxl_pci scanned through all register blocks and mapping the ones that
the driver will use. This logic is inverted so that the driver
specifically requests the register blocks from a new helper. Under the
hood, the same implementation of scanning through all register locator
DVSEC entries exists.
There are 2 behavioral changes (#2 is arguable):
1. A dev_err is introduced if cxl_map_regs fails.
2. The previous logic would try to map component registers and device
registers multiple times if there were present and keep the mapping
of the last one found (furthest offset in the register locator).
While this is disallowed in the spec, CXL 2.0 8.1.9: "Each register
block identifier shall only occur once in the Register Locator DVSEC
structure" it was how the driver would respond to the spec violation.
The new logic will take the first found register block by type and
move on.
Signed-off-by: Ben Widawsky <redacted>
---
Changes since v1:
No changes? Luckily git am strips this section...
Overall I think this refactor can be broken down further for
readability and cleanup the long standing problem that the driver maps
component registers for no reason. The main contributing factor to
readability is that cxl_setup_pci_regs() still exists after the
refactor, which also contributes to the component register problem. If
the register mapping is up leveled to the caller of
cxl_setup_pci_regs() (and drops mapping component registers) then a
follow-on patch to rename cxl_setup_pci_regs to find_register_block
becomes easier to read. Moving the cxl_register_map array out of
cxl_setup_pci_regs() also makes a later patch to pass component
register enumeration details to the endpoint-port that much cleaner.
From: Dan Williams <hidden> Date: 2021-09-28 17:42:20
On Thu, Sep 23, 2021 at 10:27 AM Ben Widawsky [off-list ref] wrote:
The structure exists to pass around information about register mapping.
Using it more extensively cleans up many existing functions.
I would have liked to have seen "add @base to cxl_register_map" and
"use @map for @bar and @offset arguments" somewhere in this changelog
to set expectations for what changes are included. That would have
also highlighted that adding a @base to cxl_register_map deserves its
own patch vs the conversion of @bar and @offset to instead use
@map->bar and @map->offset. Can you resend with that split and those
mentions?
@@ -5398,20 +5398,7 @@ static int intel_iommu_disable_sva(struct device *dev)*/staticintsiov_find_pci_dvsec(structpci_dev*pdev){-intpos;-u16vendor,id;--pos=pci_find_next_ext_capability(pdev,0,0x23);-while(pos){-pci_read_config_word(pdev,pos+4,&vendor);-pci_read_config_word(pdev,pos+8,&id);-if(vendor==PCI_VENDOR_ID_INTEL&&id==5)-returnpos;--pos=pci_find_next_ext_capability(pdev,pos,0x23);-}--return0;+returnpci_find_dvsec_capability(pdev,PCI_VENDOR_ID_INTEL,5);}
Same comments as the CXL patch, siov_find_pci_dvsec() doesn't seem to
have a reason to exist anymore. What is 5?
"5" is DVSEC ID for Scalable IOV.
Anyway, the siov_find_pci_dvsec() has been dead code since commit
262948f8ba57 ("iommu: Delete iommu_dev_has_feature()"). I have a patch
to clean it up. No need to care about it in this series.
Best regards,
baolu
From: Jonathan Cameron <hidden> Date: 2021-10-01 10:00:52
On Thu, 23 Sep 2021 10:26:44 -0700
Ben Widawsky [off-list ref] wrote:
Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
Extended Capability with the specified DVSEC ID.
The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
more vendor specific capabilities that aren't tied to the vendor ID of
the PCI component.
DVSEC is critical for both the Compute Express Link (CXL) driver as well
as the driver for OpenCAPI coherent accelerator (OCXL).
Cc: David E. Box <david.e.box@linux.intel.com>
Cc: Jonathan Cameron <redacted>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Dan Williams <redacted>
Cc: linux-pci@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Andrew Donnellan <redacted>
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Frederic Barrat <redacted>
Signed-off-by: Ben Widawsky <redacted>
Great to see this cleaned up.
Reviewed-by: Jonathan Cameron <redacted>