Linux Documentation
 help / color / mirror / Atom feed
From: Aksh Garg <a-garg7@ti.com>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: <linux-pci@vger.kernel.org>, <linux-doc@vger.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 v3 3/4] PCI: endpoint: Add API for DOE initialization and setup in EPC core
Date: Fri, 15 May 2026 10:21:52 +0530	[thread overview]
Message-ID: <3853ba15-d096-4cf4-b52f-8a2e5f50fe53@ti.com> (raw)
In-Reply-To: <m4z3q3pe3ro5vkl4uq4zkewpjdqccgeact2hj4tjnkonttx4vr@ndan37zzwgxc>



On 14/05/26 13:38, Manivannan Sadhasivam wrote:
> On Mon, Apr 27, 2026 at 10:47:24AM +0530, Aksh Garg wrote:
>> Add pci_epc_setup_doe() API in EPC core driver to initialize and setup
>> the DOE framework for an endpoint controller. The API discovers the DOE
>> capabilities (extended capability ID 0x2E), and registers each discovered
>> DOE mailbox for all the functions in the endpoint controller. This API
>> should be invoked by the controller driver during probe based on the
>> doe_capable feature.
>>
>> Add pci_epc_destroy_doe() API in EPC core driver for cleanup of DOE
>> resources, which should be invoked by the controller driver during
>> controller cleanup based on the doe_capable feature.
>>
>> 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 v2 to v3:
>> - Rebased on 7.1-rc1.
>>
>> Changes since v1:
>> - New patch added to v2 (not present in v1)
>>
>> 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].
>>
> 
> Sweet! But I was expecting you to add atleast one EPC driver implementation to
> make use of these APIs.
> 
> Also, why can't you call these APIs from the EPC core directly? Maybe during
> pci_epc_init_notify() once the register accesses become valid.

Can we add the DOE initialization API to pci_epc_init_notify()? This
API seems to be called to notify the EPF drivers that the EPC device's
initialization has been completed, as the name and description suggests.
As 'pci_epc_doe_setup' is a part of EPC initialization, I thought the
EPC drivers should call this API before calling the pci_epc_init_notify().

However, I agree with your suggestion to call the DOE setup API directly
from the EPC core instead of sprinkling over the EPC drivers. I would
recommend renaming the pci_epc_init_notify() API (and hence the
pci_epc_deinit_notify() as well) to something like 
pci_epc_init_complete(), and add the DOE setup API/logic just before the
logic of notifying the EPF devices.

Please suggest if the above would be acceptable.

Regards,
Aksh Garg

> 
> - Mani
> 
>> [1]: https://lore.kernel.org/all/p57x6jleaim5w7t2k3v7tioujnaxuovfpj5euop5ogefvw23se@y5fw3che5p5d/
>>
>>   drivers/pci/endpoint/pci-epc-core.c | 71 +++++++++++++++++++++++++++++
>>   include/linux/pci-epc.h             | 21 +++++++++
>>   2 files changed, 92 insertions(+)
>>
>> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
>> index 6c3c58185fc5..5a95a07b7d3a 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",
>>   };
>> @@ -548,6 +550,75 @@ void pci_epc_mem_unmap(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
>>   }
>>   EXPORT_SYMBOL_GPL(pci_epc_mem_unmap);
>>   
>> +/**
>> + * pci_epc_doe_setup() - Setup and discover 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.
>> + *
>> + * This API should be called by the controller driver during initialization
>> + * if DOE support is available (indicated by doe_capable in pci_epc_features).
>> + *
>> + * RETURNS: 0 on success, -errno on failure
>> + */
>> +int pci_epc_doe_setup(struct pci_epc *epc)
>> +{
>> +	u16 cap_offset = 0;
>> +	u8 func_no;
>> +	int ret;
>> +
>> +	if (!epc || !epc->ops || !epc->ops->find_ext_capability)
>> +		return -EINVAL;
>> +
>> +	/* Initialize DOE framework for this controller */
>> +	ret = pci_ep_doe_init(epc);
>> +	if (ret)
>> +		return ret;
>> +
>> +	/* Discover DOE capabilities for all functions */
>> +	for (func_no = 0; func_no < epc->max_functions; func_no++) {
>> +		while ((cap_offset = epc->ops->find_ext_capability(epc, func_no, 0,
>> +								   cap_offset,
>> +								   PCI_EXT_CAP_ID_DOE))) {
>> +			/* Register this DOE mailbox */
>> +			ret = pci_ep_doe_add_mailbox(epc, func_no, cap_offset);
>> +			if (ret) {
>> +				dev_err(&epc->dev,
>> +					"[pf%d:offset %x] failed to add DOE mailbox\n",
>> +					func_no, cap_offset);
>> +			}
>> +		}
>> +	}
>> +
>> +	dev_dbg(&epc->dev, "DOE mailboxes setup complete\n");
>> +	return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(pci_epc_doe_setup);
>> +
>> +/**
>> + * pci_epc_doe_destroy() - Destroy and cleanup DOE mailboxes
>> + * @epc: the EPC device on which DOE mailboxes has to be destroyed
>> + *
>> + * Destroy all DOE mailboxes registered on this endpoint controller and
>> + * free associated resources.
>> + *
>> + * This API should be called by the controller driver during controller cleanup
>> + * if DOE support is available (indicated by doe_capable in pci_epc_features).
>> + *
>> + * RETURNS: 0 on success, -errno on failure
>> + */
>> +int pci_epc_doe_destroy(struct pci_epc *epc)
>> +{
>> +	if (!epc)
>> +		return -EINVAL;
>> +
>> +	pci_ep_doe_destroy(epc);
>> +	dev_dbg(&epc->dev, "DOE mailboxes destroyed\n");
>> +	return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(pci_epc_doe_destroy);
>> +
>>   /**
>>    * pci_epc_clear_bar() - reset the BAR
>>    * @epc: the EPC device for which the BAR has to be cleared
>> diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
>> index dd26294c8175..7b0f258ef330 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;
>>   };
>> @@ -368,6 +374,21 @@ int pci_epc_mem_map(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
>>   void pci_epc_mem_unmap(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
>>   		       struct pci_epc_map *map);
>>   
>> +#ifdef CONFIG_PCI_ENDPOINT_DOE
>> +int pci_epc_doe_setup(struct pci_epc *epc);
>> +int pci_epc_doe_destroy(struct pci_epc *epc);
>> +#else
>> +static inline int pci_epc_doe_setup(struct pci_epc *epc)
>> +{
>> +	return -EOPNOTSUPP;
>> +}
>> +
>> +static inline int pci_epc_doe_destroy(struct pci_epc *epc)
>> +{
>> +	return -EOPNOTSUPP;
>> +}
>> +#endif
>> +
>>   #else
>>   static inline void pci_epc_init_notify(struct pci_epc *epc)
>>   {
>> -- 
>> 2.34.1
>>
> 


  reply	other threads:[~2026-05-15  4:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-27  5:17 [PATCH v3 0/4] PCI: Add DOE support for endpoint Aksh Garg
2026-04-27  5:17 ` [PATCH v3 1/4] PCI/DOE: Move common definitions to the header file Aksh Garg
2026-04-27  5:17 ` [PATCH v3 2/4] PCI: endpoint: Add DOE mailbox support for endpoint functions Aksh Garg
2026-05-14  8:03   ` Manivannan Sadhasivam
2026-05-15  5:35     ` Aksh Garg
2026-05-15 12:40       ` Manivannan Sadhasivam
2026-04-27  5:17 ` [PATCH v3 3/4] PCI: endpoint: Add API for DOE initialization and setup in EPC core Aksh Garg
2026-05-14  8:08   ` Manivannan Sadhasivam
2026-05-15  4:51     ` Aksh Garg [this message]
2026-05-15 12:47       ` Manivannan Sadhasivam
2026-04-27  5:17 ` [PATCH v3 4/4] Documentation: PCI: Add documentation for DOE endpoint support Aksh Garg
2026-05-14  8:11   ` Manivannan Sadhasivam
2026-05-14  8:12 ` [PATCH v3 0/4] PCI: Add DOE support for endpoint Manivannan Sadhasivam

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=3853ba15-d096-4cf4-b52f-8a2e5f50fe53@ti.com \
    --to=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