Re: [PATCH v2 03/15] firmware: arm_scmi: Use mbox_ring_doorbell() instead of NULL message

[Cristian Marussi <cristian.marussi@arm.com>]

On Sat, Feb 07, 2026 at 08:01:25PM -0800, Douglas Anderson wrote:
> As per the patch ("mailbox: Deprecate NULL mbox messages; Introduce
> mbox_ring_doorbell()"), we want to switch all users of NULL mailbox
> messages to use mbox_ring_doorbell().

Hi,

> 
> The mbox_ring_doorbell() explicitly documents not to call
> mbox_client_txdone() for doorbells, so remove the call.
> 
> NOTE: this mailbox client appears to send doorbells and regular
> messages on the same mailbox channel (smbox->chan), so it needs some
> extra attention. Specifically, the new API behaves differently if you
> ring a doorbell while a non-doorbell message is in progress. I don't
> believe that this is something we have to worry about with this
> mailbox client, though, because the code was calling
> mbox_client_txdone() after sending the NULL message. Had a non-mailbox
> message been in progress, that would have marked the in-progress
> message as done instead of marking the NULL message as done.
> 

Yes indeed in the SCMI stack on Linux we use both regular non-doorbell
messaging for cmd/reply exchanges and 'pure' doorbell messaging, where
these latter usually are meant to to signal completion and they are
issued on a distinct channel where NO non-doorbell message is sent
ever: IOW doorbell and non-doorbell do NOT get mixed up in the same
channel...so it should safe...

...having said that, just in case, I tested this series on a JUNO
board using ARM MHU (bidirectional) mailboxes and I have NOT seen any
anomaly.

Tested-by: Cristian Marussi <cristian.marussi@arm.com>

Anyway...Sudeep, who was already in CC, has a couple of mailbox/pcc
related series in flight on the list, so he may want to chime in on
those.

Btw, Thanks for this cleanup !
Now the intent is certainly more explicit and less ambiguous than using
a dummy NULL message to trigger a doorbell.

Thanks,
Cristian