From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Evangelos Petrongonas <epetron@amazon.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Alex Williamson <alex.williamson@redhat.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
David Matlack <dmatlack@google.com>,
Vipin Sharma <vipinsh@google.com>, Chris Li <chrisl@kernel.org>,
Jason Miu <jasonmiu@google.com>,
"Pratyush Yadav" <pratyush@kernel.org>,
Stanislav Spassov <stanspas@amazon.de>,
<linux-pci@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <nh-open-source@amazon.com>
Subject: Re: [RFC PATCH 04/13] pci: pcsc: infer PCIe extended capabilities
Date: Thu, 9 Oct 2025 15:24:15 +0100 [thread overview]
Message-ID: <20251009152415.00000b07@huawei.com> (raw)
In-Reply-To: <026b1d3e3fcb2a554511de3f23d6a7640b5377b6.1759312886.git.epetron@amazon.de>
On Fri, 3 Oct 2025 09:00:40 +0000
Evangelos Petrongonas <epetron@amazon.de> wrote:
> Extend PCSC to support cacheability inference for PCIe extended
> capabilities located in the 4KB extended configuration space.
>
> Similar to the capabilities, PCIe extended capabilities require
> traversal of the capability list to determine cacheability. The
> implementation identifies cacheable registers for capabilities used
> by the generic PCIe driver:
>
> - Advanced Error Reporting (AER)
> - Access Control Services (ACS)
> - Alternative Routing-ID (ARI)
> - SR-IOV
> - Address Translation Services (ATS)
> - Page Request Interface (PRI)
> - Process Address Space ID (PASID)
> - Downstream Port Containment (DPC)
> - Precision Time Measurement (PTM)
>
> The extended capability header (4 bytes) is always cached to enable
> efficient capability list traversal.
>
> All the extended capabilities apart from the DPC are static. Regarding
> DPC, the DPC capabilities is read and based on its value the
> cacheability of RP* registers is inferred.
>
> Signed-off-by: Evangelos Petrongonas <epetron@amazon.de>
> Signed-off-by: Stanislav Spassov <stanspas@amazon.de>
A few comments below.
> ---
> drivers/pci/pcsc.c | 203 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 203 insertions(+)
>
> diff --git a/drivers/pci/pcsc.c b/drivers/pci/pcsc.c
> index 29945eac4190..343f8b03831a 100644
> --- a/drivers/pci/pcsc.c
> +++ b/drivers/pci/pcsc.c
> +static void infer_extended_capabilities_pointers(struct pci_dev *dev)
> +{
> + int pos = 0x100;
> + u32 header;
> + int cap_ver, cap_id;
> + int i;
> +
if (!IS_ENABLED(CONFIG_PCIE_PCSC))
return;
is probably enough to allow the compiler to get rid of everything without
the ifdef magic.
> + while (pos) {
> + if (pos > 0xFFC || pos < 0x100)
> + break;
> +
> + pos &= ~0x3;
> +
> + if (pcsc_hw_config_read(dev->bus, dev->devfn, pos, 4,
> + &header) != PCIBIOS_SUCCESSFUL)
> + break;
> +
> + if (!header)
> + break;
> +
> + bitmap_set(dev->pcsc->cachable_bitmask, pos, 4);
> + for (i = 0; i < 4; i++)
> + pcsc_update_byte(dev, pos + i,
> + (header >> (i * 8)) & 0xFF);
> +
> + cap_id = PCI_EXT_CAP_ID(header);
> + cap_ver = PCI_EXT_CAP_VER(header);
> +
> + pci_dbg(dev,
> + "Extended capability ID %#x (ver %d) found at %#x, next cap at %#x\n",
> + cap_id, cap_ver, pos, PCI_EXT_CAP_NEXT(header));
> +
> + /* Check if this is a supported extended capability and infer cacheability */
> + for (i = 0; i < ARRAY_SIZE(PCSCS_SUPPORTED_EXT_CAPABILITIES);
> + i++) {
> + if (cap_id == PCSCS_SUPPORTED_EXT_CAPABILITIES[i]) {
> + infer_extended_capability_cacheability(dev, pos,
> + cap_id);
> + break;
> + }
> + }
> +
> + pos = PCI_EXT_CAP_NEXT(header);
> + }
> +}
> +#endif
> +
> static void infer_cacheability(struct pci_dev *dev)
> {
> if (WARN_ON(!dev || !dev->pcsc || !dev->pcsc->cfg_space))
> @@ -432,6 +631,10 @@ static void infer_cacheability(struct pci_dev *dev)
> }
>
> infer_capabilities_pointers(dev);
> +#ifdef CONFIG_PCIE_PCSC
> + if (pci_is_pcie(dev))
> + infer_extended_capabilities_pointers(dev);
> +#endif
> }
> }
>
next prev parent reply other threads:[~2025-10-09 14:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-03 9:00 [RFC PATCH 00/13] Introduce PCI Configuration Space Cache (PCSC) Evangelos Petrongonas
2025-10-03 9:00 ` [RFC PATCH 01/13] pci: pcsc: Add plumbing for the " Evangelos Petrongonas
2025-10-09 12:38 ` Jonathan Cameron
2025-10-03 9:00 ` [RFC PATCH 02/13] pci: pcsc: implement basic functionality Evangelos Petrongonas
2025-10-09 13:12 ` Jonathan Cameron
2025-10-03 9:00 ` [RFC PATCH 03/13] pci: pcsc: infer cacheability of PCI capabilities Evangelos Petrongonas
2025-10-09 14:17 ` Jonathan Cameron
2025-10-03 9:00 ` [RFC PATCH 04/13] pci: pcsc: infer PCIe extended capabilities Evangelos Petrongonas
2025-10-09 14:24 ` Jonathan Cameron [this message]
2025-10-03 9:00 ` [RFC PATCH 05/13] pci: pcsc: control the cache via sysfs and kernel params Evangelos Petrongonas
2025-10-09 14:41 ` Jonathan Cameron
2025-10-03 9:00 ` [RFC PATCH 06/13] pci: pcsc: handle device resets Evangelos Petrongonas
2025-10-09 14:49 ` Jonathan Cameron
2025-10-03 9:00 ` [RFC PATCH 07/13] pci: pcsc: introduce statistic gathering tools Evangelos Petrongonas
2025-10-09 14:56 ` Jonathan Cameron
2025-10-03 9:00 ` [RFC PATCH 08/13] pci: Save only spec-defined configuration space Evangelos Petrongonas
2025-10-04 1:59 ` kernel test robot
2025-10-09 14:58 ` Jonathan Cameron
2025-10-03 9:00 ` [RFC PATCH 09/13] vfio: pci: Fill only spec-defined configuration space regions Evangelos Petrongonas
2025-10-03 9:00 ` [RFC PATCH 10/13] pci: pcsc: Use contiguous pages for the cache data Evangelos Petrongonas
2025-10-03 9:00 ` [RFC PATCH 11/13] pci: pcsc: Add kexec persistence support via KHO Evangelos Petrongonas
2025-10-03 9:00 ` [RFC PATCH 12/13] pci: pcsc: introduce persistence versioning Evangelos Petrongonas
2025-10-03 9:00 ` [RFC PATCH 13/13] pci: pcsc: introduce hashtable lookup to speed up restoration Evangelos Petrongonas
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=20251009152415.00000b07@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=chrisl@kernel.org \
--cc=dmatlack@google.com \
--cc=epetron@amazon.de \
--cc=jasonmiu@google.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=nh-open-source@amazon.com \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rafael@kernel.org \
--cc=stanspas@amazon.de \
--cc=vipinsh@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.