On 9/4/25 07:00, Sudeep Holla wrote:

On Mon, Jul 14, 2025 at 08:10:07PM -0400,admiyo@os.amperecomputing.com wrote:

quoted

From: Adam Young<redacted>

Define a new, optional, callback that allows the driver to
specify how the return data buffer is allocated.  If that callback
is set,  mailbox/pcc.c is now responsible for reading from and
writing to the PCC shared buffer.

This also allows for proper checks of the Commnand complete flag
between the PCC sender and receiver.

For Type 4 channels, initialize the command complete flag prior
to accepting messages.

Since the mailbox does not know what memory allocation scheme
to use for response messages, the client now has an optional
callback that allows it to allocate the buffer for a response
message.

When an outbound message is written to the buffer, the mailbox
checks for the flag indicating the client wants an tx complete
notification via IRQ.  Upon receipt of the interrupt It will
pair it with the outgoing message. The expected use is to
free the kernel memory buffer for the previous outgoing message.

I know this is merged. Based on the discussions here, I may send a revert
to this as I don't think it is correct.

Have you decided what to do?  The MCTP over PCC driver depends on the 
behavior in this patch. If you do revert, I will need a path forward.

Based on other code review feed back, I need to make an additional 
change:  the rx_alloc callback function needs to be atomically set, and 
thus needs to move to the mailbox API.  There it will pair with the 
prepare transaction function.  It is a small change, but I expect some 
feedback from the mailbox maintainers.

I know all of the other drivers that use the PCC mailbox currently do 
direct management of the shared buffer.  I suspect that is the biggest 
change that is causing you concern.  Are you OK with maintaining a 
mailbox-managed path to buffer management as well?  I think it will be 
beneficial to other drivers in the long run.