Re: [PATCH 3/4] mailbox: add direct synchronous send support

[Anup Patel]

Hi Jassi,

On Mon, Oct 12, 2026 at 5:52 AM Jassi Brar <jassisinghbrar@xxxxxxxxx> wrote:
>
> On Wed, Sep 30, 2026 at 10:06 AM Anup Patel <anup.patel@xxxxxxxxxxxxxxxx> wrote:
> >
> > From: Amirreza Zarrabi <amirreza.zarrabi@xxxxxxxxxxxxxxxx>
> >
> > Some mailbox controllers can complete a transaction entirely within
> > the calling context, without going through the queued TX state
> > machine or a TX-done interrupt. Add a synchronous send path so their
> > clients can request one and wait for the result directly.
> >
> > Controllers advertise support via the new send_data_sync() op and
> > clients opt in by setting tx_sync when requesting the channel.
> >
> > Channels bound this way must not call mbox_chan_txdone() or
> > mbox_client_txdone(), and mbox_send_message() and mbox_flush() now
> > reject them, since only mbox_send_message_sync() is a valid
> > transmit path. The client remains responsible for serializing calls
> > to mbox_send_message_sync() against mbox_free_channel().
> >
> Seems like you want to use mbox_client.tx_block.
>

Apologies for the delayed response, the past month I was travelling
followed by the Linux-7.4 merge window.

We had tried mbox_client.tx_block method in the past and we had
found it to be not suitable because the mbox_send_message() will
use wait_for_completion_timeout() which crashes when called from
an atomic (non-sleepable) context. Our existing mailbox clients (such
as system msi, clock, etc) do mailbox transfers in an atomic context.
Due to this reason, currently we set mbox_client.tx_block = false &
mbox_client.knows_txdone = true in all our mailbox client drivers.

Using mbox_client.tx_block = false & mbox_client.knows_txdone = true
still does not avoid the spinlock serialization enforced by msg_submit()
function which works fine but adds unnecessary overhead and prevents
parallel message Tx from multiple CPUs to the same SBI MPXY mailbox
channel.

The SBI MXPY mailbox controller driver simply sends messages to
higher privilege firmware upon Tx using SBI calls and when the call
returns the response data is returned with it. Also, there is no Tx complete
interrupt. The higher privilege firmware may forward this message to a
microcontroller over RPMI queues OR it may context-switch and forward
this message to a secured domain (e.g. OP-TEE) to process the message.
The higher privilege firmware takes care of the serialization and also allows
parallel SBI MPXY calls from multiple CPUs.

The MBOX_TXDONE_BY_RETURN and send_data_sync() callback
allows us to avoid the Tx queuing and "chan->lock" for SBI MPXY mailbox
channels since this is already taken care of by the higher privilege firmware.

Regards,
Anup