From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8170A32E6BF for ; Thu, 18 Dec 2025 08:12:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766045520; cv=none; b=i8szGOfkyJUXP7VrdXaRiymzthc5NEI5PaN7ljfhdYjjm3zokHicneBEKGE5kNSFIBvltHXRt1M2h1tpVNOYZi4TL/MUmy61j1HS1/j677JaQKhJNtNQb9jbHCUSZ7d3d5fIk/46jqQ1N/TG0MAsOFnZrUXDs5eD/Rb7iWBDfhI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766045520; c=relaxed/simple; bh=UkPfvehpr5WMMSbqQFekp6Ak+CNrNqBPPGazSGHKEJY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dZVneE6RgFj2qZ1gcHXu6TBIhQbuFzIKvjYLxi5pw6rZntYOys3X/DMIMP61+4oyzZfrUSbrGY7tQweWGaZgkxYAOgf+9QMQ/IWoQPKyeYPI6gDCXDBG6B98L/Ow4gXLtKvdSLusTo6NITNOzeD6+v+dIhQYJ5D3FGWlggFLqJk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fwZF/UaU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fwZF/UaU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89304C4CEFB; Thu, 18 Dec 2025 08:11:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1766045520; bh=UkPfvehpr5WMMSbqQFekp6Ak+CNrNqBPPGazSGHKEJY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fwZF/UaUVzRs4c8qkHW39wrP53MZ+3A1yialPsFZ/MmsvZbxznqdqxO1uK5gLQKJp VIuXnxE+kdd5rFhfxi0tKUYEAiWY7g8Hc5SL+N3Jr49QgwmIpkY0FukN48vyhIr7Ue rZjoulcIwj8O2hx5iOL344Dksqt6/7081LAYmxWNjmmC0MgSOqtSAteiR4jOtr39xx pItXzKiWOyRa4bOAf5G34CwPWjcipNemWxdIq/h4fFWCiql6+gjxFDuNK4+Ktfv5M7 ya8eb+JDvbFGWwy7MPdNlqSHyZ4aePM06rrfnXrcTVbhnrly5xkfVWjQOOinyFIwWY oHo/nQ/hovenA== Date: Thu, 18 Dec 2025 08:11:55 +0000 From: Lee Jones To: Joonwon Kang Cc: jassisinghbrar@gmail.com, jonathanh@nvidia.com, linux-kernel@vger.kernel.org, sudeep.holla@arm.com, thierry.reding@gmail.com Subject: Re: [PATCH] mailbox: Allow NULL message sending Message-ID: <20251218081155.GA2061313@google.com> References: <20251208065117.1664403-1-joonwonkang@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20251208065117.1664403-1-joonwonkang@google.com> On Mon, 08 Dec 2025, Joonwon Kang wrote: > On Wed, Dec 3, 2025 at 11:57 PM Joonwon Kang wrote: > > > > > > On Tue, Nov 25, 2025 at 11:00 PM Joonwon Kang wrote: > > > > > > > > > > Clients may want to send interrupt only without any useful message > > > > > involved. Since the current mailbox framework does not allow NULL > > > > > message sending(although it allows receiving it), the clients should > > > > > allocate a dummy message buffer and pretend sending it. Besides, if > > > > > the mailbox controller calls `mbox_chan_txdone()` when the client > > > > > drivers happen to send NULL message anyway, it will result in unexpected > > > > > results by making the tx status messed up. This commit lifts the > > > > > limitation and allows the clients to send interrupt only without any > > > > > message buffer allocated. > > > > > > > > > Interrupts without data messages are called 'doorbells' and we already > > > > support them. > > > > thanks > > > > > > I am not sure if it is already supported. Let me draw two cases which imply > > > that it is not supported. If the cases make sense, could you reconsider the > > > patch? If it is supported in another branch, could you refer me to that > > > branch? I am currently referring to the `for-next` branch of your mailbox > > > repo. > > > > > I believe you are talking about some hypothetical situation? > > Otherwise, which controller is that? > > A controller driver is supposed to either expect data or not, but not both. > > I did not notice this controller's expectation since I could not find this info > in the API doc. So, now I believe that Case 2 could be seen as a hypothetical > situation. However, what about Case 1? If the message to send is NULL, > `chan->cl->tx_done(chan->cl, mssg, r)` and `complete(&chan->tx_complete)` will > **never** be called from `tx_tick()`. It also means that there is no way for a > client to know that the sending is really done or not. Even though a controller > driver(I mean any typical controller, not a specific controller) calls > `mbox_chan_txdone()` after receiving the corresponding ACK interrupt from the > remote to the previously sent NULL message, the client will be blocking not > knowing the sending is done. It's been a long time since I had anything to do with the Mailbox subsystem, but as a drive-by comment, I wonder if my mailbox-test driver could be expanded to test and prove out the concept of doorbells. -- Lee Jones [李琼斯]