drivers: mbox: imx_mu: ignore TriggerInterrupt failures

The ipc backends, like icmsg.c, don't expect errors when
using mailbox send for notifications. In some places,
icmsg.c ignores the return value of the mailbox send,
in some places it propagates the error up, and in some
places it asserts.

icmsg only uses the mailbox send with NULL msg as a means
to interrupt the other processor, and all data is passed
via shared memory. So it is safe to ignore the case when
the interrupt is already pending, since the other
processor should handle the pending message when it gets
around the handling the interrupt. As long as the order
of clearing the interrupt is before the handling of the
data, there should be no case where not pending a new
interrupt when one is already pending would result in missing
any new message.

Signed-off-by: Mike J. Chen <[email protected]>

Author: mjchen0

drivers/mbox/mbox_nxp_imx_mu.c

@@ -63,8 +63,18 @@ static int nxp_imx_mu_send(const struct device *dev, uint32_t channel, const str
 	if (msg == NULL) {
 		if (MU_TriggerInterrupts(cfg->base, g_gen_int_trig_mask[channel]) !=
 		    kStatus_Success) {
-			/* interrupt already pending, cannot trigger again */
-			return -EAGAIN;
+			/* Ignore any error returned by MU_TriggerInterrupts().
+			 * It can return failure if the interrupt is already pending, but
+			 * don't return that as an error otherwise the ipc service
+			 * using it might assert or fail. Since ipc uses mailbox
+			 * interrupts only as notifications, and the data transfer
+			 * is via shared memory, as long as the interrupt is pending,
+			 * the other processor should read all the data when it
+			 * handles the interrupt. As long as the interrupt is cleared
+			 * before data is processed, which it is. Just LOG_DBG the
+			 * occurrence.
+			 */
+			LOG_DBG("Interrupt already pending on channel %u", channel);
 		}
 		return 0;
 	}