lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aYoPLzOjPvJbu0Kb@pluto>
Date: Mon, 9 Feb 2026 16:45:35 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: Douglas Anderson <dianders@...omium.org>
Cc: jassisinghbrar@...il.com, arm-scmi@...r.kernel.org,
	cristian.marussi@....com, krzk@...nel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	sudeep.holla@...nel.org
Subject: Re: [PATCH v2 03/15] firmware: arm_scmi: Use mbox_ring_doorbell()
 instead of NULL message

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@....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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ