Re: [RFC PATCH 3/4] PCI/DOE: Add DOE mailbox support for endpoint functions

[Aksh Garg <a-garg7@ti.com>]

On 22/02/26 18:36, Lukas Wunner wrote:
> On Fri, Feb 13, 2026 at 06:06:02PM +0530, Aksh Garg wrote:
>> Add the DOE support for PCIe endpoint devices, enabling endpoint
>> functions to process the DOE requests from the host. The implementation
>> provides framework APIs for controller drivers to register mailboxes,
>> protocol handler registration for different DOE data object types, and
>> request processing with workqueues ensuring sequential handling per
>> mailbox. The Discovery protocol is handled internally by the DOE core.
> 
> This looks like it is largely a duplication of drivers/pci/doe.c,
> including the asynchronous request support that was originally added
> but was never needed and so was clearly a mistake.
> 
> I'm wondering why the async suport is needed in the endpoint case?
> Why can't this (only) be synchronous?

The DOE framework for the endpoint case needs to be asynchronous because
a PF can have multiple instances of DOE mailboxes, and the requests may
be interleaved across the mailboxes (the request processing of one
mailbox should not result in blocking the request processing of other
mailbox, as per the DOE ECN). Hence, the request on each of them needs
to be handled in parallel for optimization. For the EP controller driver
to handle requests on multiple mailboxes per-PF in parallel,
pci_ep_doe_process_request() needs to be asynchronous.
However, I noticed the use of wait_for_completion() within this function
makes the overall function synchronous for the caller, which I
overlooked while posting this patch.


Please provide feedback if the following framework would work instead:

The function pci_ep_doe_process_request() would be called by the EP
controller driver when a request arrives on a mailbox. Instead of
wait_for_completion() in this function, the function would return
immediately after submitting the work in the queue, hence eliminating
the need of private data for completion in the task structure.

A completion callback from the EP driver would be passed to this
function along with the current parameters, which would be passed to the
task structure as task->complete. Whenever signal_task_complete() is
invoked, the completion callback of the EP driver would be called, which
would take func_no, cap_offset (to help the EP driver to identify the
mailbox), and the status of the work as input, hence eliminating the
need of task_status in the task structure as well.

This would make pci_ep_doe_process_request() asynchronous as per the
requirement.


While going through the driver implementation of doe.c, I noticed that
the pci_doe() was made synchronous in commit 62e8b17ffc2f ("PCI/DOE:
Provide synchronous API and use it internally"), which builds on the
internal asynchronous machinery using WORK_QUEUES. As the pci_doe() is
synchronous for the callers, why the WORK_QUEUE framework was not 
removed from the doe.c implementation in that commit?

> 
> Thanks,
> 
> Lukas