Re: [PATCH v23 1/2] mailbox/pcc: support mailbox management of the shared buffer
From: Sudeep Holla <hidden>
Date: 2025-09-08 15:20:35
Also in:
lkml
On Mon, Sep 08, 2025 at 10:58:55AM -0400, Adam Young wrote:
On 9/4/25 07:00, Sudeep Holla wrote:quoted
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.
Sorry not yet. I still need to understand and analyse your last reply.
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.
If you are really interesting to consolidating, then move all the buffer management into the core. Just don't introduce things that just work on your platform and for your use case. You need move all the drivers to this new model of accessing the buffers. Otherwise I see no point as it is just another churn but in core mailbox PCC driver instead of a client driver using PCC. So, I am not OK with the change as is and needs to be reworked or reverted. I need sometime to understand your email and requirements. -- Regards, Sudeep