From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DE7FC3806BD for ; Fri, 13 Mar 2026 08:44:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773391494; cv=none; b=Her9VCS8btq7FR4E0/TNOH7SwGaA1z89oy0jpi2e3x69qnLXHPSqNklgYDEdg0Nvoe8KmvBeGMZmheFSe9aTxnhSsNx+svhT1FqrbjOa2d4Uejnauzxr3dJ5O06mSA+kIBrKpvM109hQ7P/JvchTijyh/n/Y4vibtex0Pmi/TQI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773391494; c=relaxed/simple; bh=dQje3pRMO/+YTe3UWGM3JitjTt5mzdGbzz0dmMS2KOM=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=EI6zNlNFbjAZlMtuMQGRm1CQgd7FdfDgI9/5q61uzFl8p/jlEGpKJkpcdGbEDeNr6qjf321iSvTJro0JFUVxuqYsPsSWduhodArM1E4rsANvVjV6tsKfunfYvle/YEx34WeqpuCUi++0R84ntv9T1vy9aX+vOS1ED+h/ZyFF2E4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--joonwonkang.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=gAEr8QuH; arc=none smtp.client-ip=209.85.210.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--joonwonkang.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="gAEr8QuH" Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-829ad81b132so6313830b3a.1 for ; Fri, 13 Mar 2026 01:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1773391492; x=1773996292; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=LD08rjlYo26/bkNw2GNUd3OhF22UCdYPv5IDLqsupk0=; b=gAEr8QuHZJyg06k73rM+kqM9SMSgcUWTBo8+bi+esxBXaZbCaySI8PlscNBSUJ7all nYrIcDIh72sTrHuP3r1Ijd8q6VTMIO+YYJQcJXNRKHrjGuQib2cGCCSy0fn9ok2bQBle U43ejKzkfjO9Ww4oyw+78GvXmjvFZiaSYL3hgapgXmIVvhzDlvda4FvYk2rknYabJ1YJ pzVEnJ66HGYYaCd3+wF764u12nEOtChY9AC/yrzIO5IObvCa9lasUEYU0VzLzXWmJQEc M0qsdHGlguatOZAv4JWvADKtMHABV8BqaN7jT9UQYkiMJbpM0Z2G9KgAyXq+++l8W08L edRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773391492; x=1773996292; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=LD08rjlYo26/bkNw2GNUd3OhF22UCdYPv5IDLqsupk0=; b=qDGbJnz12+8WGeWV4v4ynEWm768fr0iMU4rJJuDX6U3QgMtMt3RfmokbSdzhMpwZMq N+wveGVDIzvCc6d4LtHPnZQfIxSKsI+0I0DryCQNrxfM6TUEbtVnYq5WObzHpVCC0QeP xOreaVz9cA28TdtGg7dkGYpLZW/tSdbkXhUUkbfs8pR0iXBzUkbkrNob28dPTlBw6gKN qBQSN4NbHwZWmHKbhnNozZcrKcGvK5QdrgqFBUfzwWGnRVNgg/lTOmV1n1LCs64lpVj3 XOfltzEJL1JYJHLzhW3V++FvMt6DdaAGvY452z1l28q7nrQw2G97siok9E5aQlPB4u/Z DH7A== X-Forwarded-Encrypted: i=1; AJvYcCWHzIVtSVY4ILPPVgtH7o3MJerhnOm3qwmMIpG4HL/EMkyAqjOU73WAlarOAT/bLLWs+uM9kQ/jcG+JAt0=@vger.kernel.org X-Gm-Message-State: AOJu0Yx2XK2BQEhTLVuix1o5UkNRhnmf/8mrGmmjASZFbe93FvWCAx91 mNUgUY0O4lMLgvb0pQr3bkZZ+pf2iyLmqj5UnY32XOiKX1+ofn6uu6bp2j5yt4Y7DFtgBOQzsnc inWAQN30wTM0gUgYSi0yF4qzGTw== X-Received: from pfbhe11.prod.google.com ([2002:a05:6a00:660b:b0:829:7dd4:c2ff]) (user=joonwonkang job=prod-delivery.src-stubby-dispatcher) by 2002:aa7:88d3:0:b0:824:374a:1407 with SMTP id d2e1a72fcca58-82a19703944mr2254175b3a.16.1773391491910; Fri, 13 Mar 2026 01:44:51 -0700 (PDT) Date: Fri, 13 Mar 2026 08:44:48 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: X-Mailer: git-send-email 2.53.0.851.ga537e3e6e9-goog Message-ID: <20260313084450.2995354-1-joonwonkang@google.com> Subject: Re: [PATCH] RFC: mailbox: Fix NULL message support in mbox_send_message() From: Joonwon Kang To: dianders@chromium.org Cc: andersson@kernel.org, arnd@arndb.de, jassisinghbrar@gmail.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Hi, >=20 > On Tue, Mar 10, 2026 at 8:42=E2=80=AFPM Jassi Brar wrote: > > > > > > > In my case, I have a mailbox driver that's currently downstream > > > > > (though I hope to change that). My mailbox controller has an inte= rrupt > > > > > for txdone, so mailbox clients _shouldn't_ call mbox_client_txdon= e(). > > > > > Some clients of this mailbox client want the txdone interrupt, bu= t > > > > > some clients of it just care about sending doorbells. > > > > > > > > > So imx-dsp.c like? Please let me know what is lacking in the core t= o > > > > 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'l= l > > > have to figure out some sort of workaround... > > > > > You said your controller has an irq raised for the doorbell sent (?). >=20 > It has an interrupt for when the remote side receives the doorbell > (when it clears the IRQ on its side). >=20 > > If so, your clients should want to wait for that confirmation (the > > controller driver would tick via mbox_chan_txdone). >=20 > Ah, I think I see what you're saying. Functionally, I think it should > work. Pseudocode for the client: >=20 > def ring_doorbell(): > if not previous_doorbell_acked: > another_doorbell_pending =3D true > else: > previous_doorbell_acked =3D false; > mbox_send_message(NULL) >=20 > def tx_done(): > if another_doorbell_pending: > another_doorbell_pending =3D false > mbox_send_message(NULL) > else: > previous_doorbell_acked =3D true; >=20 > I think that will ensure the other side always gets at least one > future interrupt when the doorbell is rung. >=20 > 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.