On Sun, Oct 05, 2025 at 06:34:51PM -0500, Jassi Brar wrote:

On Sun, Oct 5, 2025 at 12:13 AM Adam Young
[off-list ref] wrote:

quoted

Jassi, this one needs your attention specifically.

Do you have an issue with adding this callback?  I think it will add an
important ability to the receive path for the mailbox API: letting the
client driver specify how to allocate the memory that the message is
coming in.  For general purpose mechanisms like PCC, this is essential:
the mailbox cannot know all of the different formats that the drivers
are going to require.  For example, the same system might have MPAM
(Memory Protection) and MCTP (Network Protocol) driven by the same PCC
Mailbox.

Looking at the existing code, I am not even sure if rx_alloc() is needed at all.

Let me explain...
1) write_response, via rx_alloc, is basically asking the client to
allocate a buffer of length parsed from the pcc header in shmem.
2) write_response is called from isr and even before the
mbox_chan_received_data() call.

Why can't you get rid of write_response() and simply call
    mbox_chan_received_data(chan, pchan->chan.shmem)
for the client to allocate and memcpy_fromio itself?
Ideally, the client should have the buffer pre-allocated and only have
to copy the data into it, but even if not it will still not be worse
than what you currently have.

Exactly, this is what I have been telling.

Adam,

Please share the code that you have attempted with this approach and the
problems you have faced.

-- 
Regards,
Sudeep