From: Bjorn Helgaas <helgaas@kernel.org>
To: Aksh Garg <a-garg7@ti.com>
Cc: linux-pci@vger.kernel.org, linux-doc@vger.kernel.org,
mani@kernel.org, kwilczynski@kernel.org, bhelgaas@google.com,
corbet@lwn.net, kishon@kernel.org, skhan@linuxfoundation.org,
lukas@wunner.de, cassel@kernel.org, alistair@alistair23.me,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, s-vadapalli@ti.com,
danishanwar@ti.com, srk@ti.com
Subject: Re: [PATCH v5 3/4] PCI: endpoint: Add support for DOE initialization and setup in EPC core
Date: Thu, 11 Jun 2026 14:12:52 -0500 [thread overview]
Message-ID: <20260611191252.GA499821@bhelgaas> (raw)
In-Reply-To: <20260610100256.1889111-4-a-garg7@ti.com>
On Wed, Jun 10, 2026 at 03:32:55PM +0530, Aksh Garg wrote:
> Add pci_epc_init_capabilities() in EPC core driver to initialize and
> setup the capabilities supported by the EPC driver. This calls
> pci_epc_doe_setup() to setup the DOE framework for an endpoint controller,
> which discovers the DOE capabilities (extended capability ID 0x2E), and
> registers each discovered DOE mailbox for all the functions in the
> endpoint controller.
>
> Add pci_epc_deinit_capabilities() in EPC core driver for cleanup of the
> resources used by the capabilities of the EPC driver. This calls
> pci_ep_doe_destroy() to destroy all DOE mailboxes and free associated
> resources.
>
> Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Aksh Garg <a-garg7@ti.com>
> ---
>
> Changes from v4 to v5:
> - Addressed the review comments by Sashiko
>
> Changes from v3 to v4:
> - Call DOE setup and destroy APIs directly within the EPC core, instead of
> relying on the EPC drivers to call them individually. EPC drivers do not
> need to explicitly handle DOE setup, rather the EPC core manages this
> transparently. (Suggested by Manivannan Sadhasivam).
> - Removed pci_epc_doe_destroy() API, which was just calling pci_ep_doe_destroy().
> Instead, called pci_ep_doe_destroy() directly during cleanup.
> - Called pci_ep_doe_init() before the "!epc->ops->find_ext_capability" check,
> because if doe-capable=1 and find_ext_capability() op is undefined, this
> would not initialize the epc->doe_mbs xarray. However during cleanup, the
> check "!epc->ops->find_ext_capability" would be unnecessary, and it will
> try to destroy the epc->doe_mbs xarray even when it was not initialized.
>
> Changes from v2 to v3:
> - Rebased on 7.1-rc1.
>
> Changes since v1:
> - New patch added to v2 (not present in v1)
>
> v4: https://lore.kernel.org/all/20260522052434.802034-4-a-garg7@ti.com/
> v3: https://lore.kernel.org/all/20260427051725.223704-4-a-garg7@ti.com/
> v2: https://lore.kernel.org/all/20260401073022.215805-4-a-garg7@ti.com/
>
> This patch is introduced based on the feedback provided by Manivannan
> Sadhasivam at [1].
>
> [1]: https://lore.kernel.org/all/p57x6jleaim5w7t2k3v7tioujnaxuovfpj5euop5ogefvw23se@y5fw3che5p5d/
>
>
> drivers/pci/endpoint/pci-epc-core.c | 104 ++++++++++++++++++++++++++++
> include/linux/pci-epc.h | 6 ++
> 2 files changed, 110 insertions(+)
>
> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> index 6c3c58185fc5..e48f40eeed29 100644
> --- a/drivers/pci/endpoint/pci-epc-core.c
> +++ b/drivers/pci/endpoint/pci-epc-core.c
> @@ -14,6 +14,8 @@
> #include <linux/pci-epf.h>
> #include <linux/pci-ep-cfs.h>
>
> +#include "../pci.h"
> +
> static const struct class pci_epc_class = {
> .name = "pci_epc",
> };
> @@ -842,6 +844,81 @@ void pci_epc_linkdown(struct pci_epc *epc)
> }
> EXPORT_SYMBOL_GPL(pci_epc_linkdown);
>
> +/**
> + * pci_epc_doe_setup() - Discover and setup DOE mailboxes for all functions
> + * @epc: the EPC device on which DOE mailboxes has to be setup
> + *
> + * Discover DOE (Data Object Exchange) capabilities for all physical functions
> + * in the endpoint controller and register DOE mailboxes.
> + *
> + * Returns: 0 on success, -errno on failure
> + */
> +static int pci_epc_doe_setup(struct pci_epc *epc)
> +{
> + u8 func_no, vfunc_no = 0;
> + u16 cap_offset;
> + int ret;
> +
> + if (!epc->ops || !epc->ops->find_ext_capability)
> + return -EINVAL;
I don't see anything that sets pci_epc_ops.find_ext_capability in this
series, so this looks currently unused and untestable, so likely not
mergeable as-is. What's the plan for users of this?
> + /* Discover DOE capabilities for all functions */
> + for (func_no = 0; func_no < epc->max_functions; func_no++) {
> + mutex_lock(&epc->lock);
> + cap_offset = epc->ops->find_ext_capability(epc, func_no,
> + vfunc_no, 0,
> + PCI_EXT_CAP_ID_DOE);
> + mutex_unlock(&epc->lock);
> +
> + while (cap_offset) {
> + /* Register this DOE mailbox */
> + ret = pci_ep_doe_add_mailbox(epc, func_no, cap_offset);
> + if (ret) {
> + dev_warn(&epc->dev,
> + "[pf%d:offset %x] failed to add DOE mailbox\n",
> + func_no, cap_offset);
> + }
> +
> + mutex_lock(&epc->lock);
> + cap_offset = epc->ops->find_ext_capability(epc, func_no,
> + vfunc_no, cap_offset,
> + PCI_EXT_CAP_ID_DOE);
> + mutex_unlock(&epc->lock);
> + }
> + }
> +
> + dev_dbg(&epc->dev, "DOE mailboxes setup complete\n");
> + return 0;
> +}
> +
> +/**
> + * pci_epc_init_capabilities() - Initialize EPC capabilities
> + * @epc: the EPC device whose capabilities need to be initialized
> + *
> + * Invoke to initialize capabilities supported by the EPC device.
s/Invoke to initialize/Initialize/
> + */
> +static void pci_epc_init_capabilities(struct pci_epc *epc)
> +{
> + const struct pci_epc_features *epc_features;
> + int ret;
> +
> + epc_features = pci_epc_get_features(epc, 0, 0);
> + if (!epc_features)
> + return;
> +
> + if (IS_ENABLED(CONFIG_PCI_ENDPOINT_DOE) && epc_features->doe_capable) {
> + ret = pci_ep_doe_init(epc);
> + if (ret) {
> + dev_warn(&epc->dev, "DOE initialization failed: %d\n", ret);
> + return;
> + }
> +
> + ret = pci_epc_doe_setup(epc);
> + if (ret)
> + dev_warn(&epc->dev, "DOE setup failed: %d\n", ret);
> + }
> +}
> +
> /**
> * pci_epc_init_notify() - Notify the EPF device that EPC device initialization
> * is completed.
> @@ -857,6 +934,9 @@ void pci_epc_init_notify(struct pci_epc *epc)
> if (IS_ERR_OR_NULL(epc))
> return;
>
> + if (!epc->init_complete)
> + pci_epc_init_capabilities(epc);
> +
> mutex_lock(&epc->list_lock);
> list_for_each_entry(epf, &epc->pci_epf, list) {
> mutex_lock(&epf->lock);
> @@ -890,6 +970,27 @@ void pci_epc_notify_pending_init(struct pci_epc *epc, struct pci_epf *epf)
> }
> EXPORT_SYMBOL_GPL(pci_epc_notify_pending_init);
>
> +/**
> + * pci_epc_deinit_capabilities() - Cleanup EPC capabilities
> + * @epc: the EPC device whose capabilities need to be cleaned up
> + *
> + * Invoke to cleanup capabilities supported by the EPC device,
> + * and free the associated resources.
s/Invoke to cleanup/Clean up/
> + */
> +static void pci_epc_deinit_capabilities(struct pci_epc *epc)
> +{
> + const struct pci_epc_features *epc_features;
> +
> + epc_features = pci_epc_get_features(epc, 0, 0);
> + if (!epc_features)
> + return;
> +
> + if (IS_ENABLED(CONFIG_PCI_ENDPOINT_DOE) && epc_features->doe_capable) {
> + pci_ep_doe_destroy(epc);
> + dev_dbg(&epc->dev, "DOE mailboxes destroyed\n");
> + }
> +}
> +
> /**
> * pci_epc_deinit_notify() - Notify the EPF device about EPC deinitialization
> * @epc: the EPC device whose deinitialization is completed
> @@ -903,6 +1004,9 @@ void pci_epc_deinit_notify(struct pci_epc *epc)
> if (IS_ERR_OR_NULL(epc))
> return;
>
> + if (epc->init_complete)
> + pci_epc_deinit_capabilities(epc);
> +
> mutex_lock(&epc->list_lock);
> list_for_each_entry(epf, &epc->pci_epf, list) {
> mutex_lock(&epf->lock);
> diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
> index dd26294c8175..11474e337db3 100644
> --- a/include/linux/pci-epc.h
> +++ b/include/linux/pci-epc.h
> @@ -84,6 +84,8 @@ struct pci_epc_map {
> * @start: ops to start the PCI link
> * @stop: ops to stop the PCI link
> * @get_features: ops to get the features supported by the EPC
> + * @find_ext_capability: ops to find extended capability offset for a function
> + * in endpoint controller
> * @owner: the module owner containing the ops
> */
> struct pci_epc_ops {
> @@ -115,6 +117,8 @@ struct pci_epc_ops {
> void (*stop)(struct pci_epc *epc);
> const struct pci_epc_features* (*get_features)(struct pci_epc *epc,
> u8 func_no, u8 vfunc_no);
> + u16 (*find_ext_capability)(struct pci_epc *epc, u8 func_no,
> + u8 vfunc_no, u16 start, u8 cap);
> struct module *owner;
> };
>
> @@ -270,6 +274,7 @@ struct pci_epc_bar_desc {
> * @msi_capable: indicate if the endpoint function has MSI capability
> * @msix_capable: indicate if the endpoint function has MSI-X capability
> * @intx_capable: indicate if the endpoint can raise INTx interrupts
> + * @doe_capable: indicate if the endpoint function has DOE capability
> * @bar: array specifying the hardware description for each BAR
> * @align: alignment size required for BAR buffer allocation
> */
> @@ -280,6 +285,7 @@ struct pci_epc_features {
> unsigned int msi_capable : 1;
> unsigned int msix_capable : 1;
> unsigned int intx_capable : 1;
> + unsigned int doe_capable : 1;
> struct pci_epc_bar_desc bar[PCI_STD_NUM_BARS];
> size_t align;
> };
> --
> 2.34.1
>
next prev parent reply other threads:[~2026-06-11 19:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 10:02 [PATCH v5 0/4] PCI: Add DOE support for endpoint Aksh Garg
2026-06-10 10:02 ` [PATCH v5 1/4] PCI/DOE: Move common definitions to the header file Aksh Garg
2026-06-11 20:36 ` Frank Li
2026-06-10 10:02 ` [PATCH v5 2/4] PCI: endpoint: Add DOE mailbox support for endpoint functions Aksh Garg
2026-06-11 19:11 ` Bjorn Helgaas
2026-06-10 10:02 ` [PATCH v5 3/4] PCI: endpoint: Add support for DOE initialization and setup in EPC core Aksh Garg
2026-06-11 19:12 ` Bjorn Helgaas [this message]
2026-06-10 10:02 ` [PATCH v5 4/4] Documentation: PCI: Add documentation for DOE endpoint support Aksh Garg
2026-06-10 23:21 ` Randy Dunlap
2026-06-11 19:12 ` Bjorn Helgaas
2026-06-11 20:47 ` [PATCH v5 0/4] PCI: Add DOE support for endpoint Frank Li
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=20260611191252.GA499821@bhelgaas \
--to=helgaas@kernel.org \
--cc=a-garg7@ti.com \
--cc=alistair@alistair23.me \
--cc=bhelgaas@google.com \
--cc=cassel@kernel.org \
--cc=corbet@lwn.net \
--cc=danishanwar@ti.com \
--cc=kishon@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mani@kernel.org \
--cc=s-vadapalli@ti.com \
--cc=skhan@linuxfoundation.org \
--cc=srk@ti.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