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

[Jassi Brar]

On Thu, Oct 29, 2026 at 7:27 AM Anup Patel <anup.patel@xxxxxxxxxxxxxxxx> wrote:
>
> 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.
>
1) Your clocks can't really expect to be atomic  -
rpmi_clk_enable/disable are prepare/unprepare callbacks which can be
called from a sleepable context anyway.
2) System-MSI is a good candidate which makes me notice the shmem is
per-cpu so currently a wider-scoped channel lock is protecting it. If
you want lock-free access to the channel you need to guard shmem
access with local_irq_save/restore which is anyway what should have
been doing.

For the system-msi case I think the framework can be modified to
support it better. Instead of a prolonged back-forth I have drafted
[1] support for a new lockfree api and the semantics documentation,
because I also know how other platforms may benefit. Please either add
pieces from it, or even better own it, adapt it and test it before
submitting (even replace my s.o.b if the author wants). That will be
the least effort for all of us.

Regards,
Jassi
[1] https://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox.git/log/?h=jsb/rfc-synch-xfer