[PATCH v5 3/4] PCI: endpoint: Add support for DOE initialization and setup in EPC core
Aksh Garg
a-garg7 at ti.com
Tue Jun 16 21:47:58 PDT 2026
On 16/06/26 11:52, Manivannan Sadhasivam wrote:
> On Fri, Jun 12, 2026 at 01:54:13PM +0530, Aksh Garg wrote:
>>
>>
>> On 12/06/26 00:42, Bjorn Helgaas wrote:
>>> 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 at ti.com>
>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli at ti.com>
>>>> Signed-off-by: Aksh Garg <a-garg7 at ti.com>
>>>> ---
>>>> +/**
>>>> + * 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;
>>>
>>
>> Hi Bjorn,
>>
>> Thank you for your feedback comments. I will work on them and post v6
>> series incorporating the changes.
>>
>>> 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?
>>>
>>
>> Currently there is no EPC driver upstream which supports DOE yet. However, I
>> am working on a platform which supports DOE (support for
>> which would be added soon). Mani pointed out that if EPC driver support
>> for the same is guaranteed to be added soon, the APIs can be merged
>> first.
>>
>> For the demonstration purpose, he asked to show how an EPC driver is
>> expected to use the API as a snippet in the cover letter itself.
>>
>
> I retract my previous comment here. Let's not introduce dead code in the kernel.
> We can review the series now, but cannot merge it until the EPC driver gets
> submitted.
Hi Mani,
Sure, I would prefer the series to be reviewed and gather Reviewed-by
tags by the time the EPC driver gets submitted, which would help
expedite the merge of this series later.
>
> - Mani
>
More information about the linux-arm-kernel
mailing list