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

[Aksh Garg]

Mani, Alistair

On 04/03/26 19:48, Manivannan Sadhasivam wrote:
> On Wed, Feb 18, 2026 at 02:28:23PM +1000, Alistair Francis wrote:
>> On 13/2/26 22:36, Aksh Garg wrote:
>>> From: Aksh Garg <a-garg7 at ti.com>
>>>
>>> DOE (Data Object Exchange) is a standard PCIe extended capability
>>> feature introduced in the Data Object Exchange (DOE) ECN for
>>> PCIe r5.0. It provides a communication mechanism primarily used for
>>> implementing PCIe security features such as device authentication, and
>>> secure link establishment. Think of DOE as a sophisticated mailbox
>>> system built into PCIe. The root complex can send structured requests
>>> to the endpoint device through DOE mailboxes, and the endpoint device
>>> responds with appropriate data.
>>>
>>> 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 implementation complements the existing DOE implementation for
>>> root complex in drivers/pci/doe.c.
>>
>> This looks good to me!
>>
>> I would love to see a handler implementation and integration with a driver
>> as well.
>>
>> For SPDM the handler could even be in userspace
>>
> 
> +1. We should not be introducing dead APIs.
> 
> - Mani
> 

I am planning to remove the register/unregister protocol APIs, and add a
static array of 'struct pci_doe_protocol' instead of a dynamic xarray.
By this, we would not be relying on someone to call the register
protocol on behalf of a library.
Whenever a new library comes up for DOE protocol, the library would have
the handler function, and the static array simply needs to populated
with this handler function in doe-ep.c

Please share your thoughts on this approach.

>> Alistair
>>
>>>
>>> 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>
>>> ---