Re: [PATCH] RFC: mailbox: Fix NULL message support in mbox_send_message()

[Joonwon Kang <joonwonkang@google.com>]

> Hi,
> 
> On Tue, Mar 10, 2026 at 8:42 PM Jassi Brar <jassisinghbrar@gmail.com> wrote:
> >
> > > > > In my case, I have a mailbox driver that's currently downstream
> > > > > (though I hope to change that). My mailbox controller has an interrupt
> > > > > for txdone, so mailbox clients _shouldn't_ call mbox_client_txdone().
> > > > > Some clients of this mailbox client want the txdone interrupt, but
> > > > > some clients of it just care about sending doorbells.
> > > > >
> > > > So imx-dsp.c like? Please let me know what is lacking in the core to
> > > > fully support that. Happy to look into it.
> > >
> > > I know that with my downstream mailbox client, if I let NULL messages
> > > queue up I end up with a queue of a dozen or so NULL messages. The
> > > downstream client is really taking advantage (AKA abusing) the core's
> > > current NULL behavior. It truly does want the "mbox_ring_doorbell"
> > > concept of just making sure the doorbell is asserted and returning
> > > immediately. If the core changes to start queuing NULL messages, we'll
> > > have to figure out some sort of workaround...
> > >
> > You said your controller has an irq raised for the doorbell sent (?).
> 
> It has an interrupt for when the remote side receives the doorbell
> (when it clears the IRQ on its side).
> 
> > If so, your clients should want to wait for that confirmation (the
> > controller driver would tick via mbox_chan_txdone).
> 
> Ah, I think I see what you're saying. Functionally, I think it should
> work. Pseudocode for the client:
> 
> def ring_doorbell():
>   if not previous_doorbell_acked:
>     another_doorbell_pending = true
>   else:
>     previous_doorbell_acked = false;
>     mbox_send_message(NULL)
> 
> def tx_done():
>   if another_doorbell_pending:
>     another_doorbell_pending = false
>     mbox_send_message(NULL)
>   else:
>     previous_doorbell_acked = true;
> 
> I think that will ensure the other side always gets at least one
> future interrupt when the doorbell is rung.
> 
> I guess another option would be for the mailbox controller to issue
> "tx_done" immediately for NULL messages. With no data to transmit, I
> guess one could say that as soon as the interrupt is raised that the
> data is "transmitted", so maybe this would be OK too?

One thing to note is that if the mailbox controller issues "tx_done"
immediately in the same thread that is executing
mbox_controller->send_data(), you will encounter deadlock(refer to
chan->lock on the code). Thus, it should be issued after ->send_data() or
in another thread. Either way, it is unavoidable to have window to queue
up the NULL messages in the multi-threads situation anyway. So, the key in
that case will be how quickly the queue is dequeued or how to recover from
the tx failure due to the overflow, I think.