From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.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 580A6233D88 for ; Mon, 22 Dec 2025 10:56:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766401005; cv=none; b=sFkVG1Zv0o0jhBj1IWgF4PuS4c55ptk3cyPIf/MhGPbVCAZnGaoC+6t174/0gCDMApZpxSq0k8DNBD+Njel58utBmgeCix5sWp6KRNeeGi0NJPStSEb4INVJ6UgObZV/X5BfYzhIw9ukoKZzvVxj+PzQO0VxVi81bWyeEyQpkl4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766401005; c=relaxed/simple; bh=MJX6p8osrglj3MAz2XmQxiSi62Ufgtjn8cBCA0dzIJM=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=slsU6F4QXOxg8fSHgPCqHfwzlfkD/I7YcZlQLfq8vgq8v4WxHvIbfzr00AihsiDiabw4aP1INcO1A4ZurglUbjlapbv+pfH5LgFzefffFI+9zc21y4Bu6SOUx/BtI1lVhZ1cVdh6bK8YvyTAFbtimI1gC2oGj+54Yy9gWHXTNRA= 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=J1OxL2lA; arc=none smtp.client-ip=209.85.214.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="J1OxL2lA" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-2a0f0c7a06eso75373155ad.2 for ; Mon, 22 Dec 2025 02:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1766401003; x=1767005803; 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=MJX6p8osrglj3MAz2XmQxiSi62Ufgtjn8cBCA0dzIJM=; b=J1OxL2lAKlRPtuVeK/5qtk2PQWj06z6x7AOrbh6zeLwaUSNznSvjOPCWKOwEqd2quB Do4uAiZlPKYHfUv/pB1cgyyJXIO7GuBNzMzVDM5pjf9vcbotQTCdwn1ZzKsHxvydsDgi PrOLcS7NFYTDHz8/XK0Rr5M/o+AIBiWZM1TQE8BzgJqjzDrtyyq2qQvq83UAm3TGVzEC a2afxVmnqW10NAVZUtvnaWJL02n2MiRzY9JkpDgBBmWVbBlADUODx3rYebmF3KqY1iIU WWaId6/TLnDt29BaN3Tl4HQy7NGMTUSGJgvuJ7fqUjYQDr7xVfS7hpeEsJTnyJ36iKrY eMig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766401003; x=1767005803; 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=MJX6p8osrglj3MAz2XmQxiSi62Ufgtjn8cBCA0dzIJM=; b=aautGGy9bTb+MU8EyOGLZxj5vtX1WhaFazuBdT295tG75rmNvfptDw+mg4yuvrbdJy 2HgRH7E472hG+VajXAyVIKhaFOoMP8T1Lr3HShAyJw9ZcB4Cu353BmwCUGhxmelZo2Gk 9BlEQEXeUjxS/1uQvygL9EqKlhc+20pZHVA8PQVeS6OpCMPJWmHav/O0FvCUlJMye20O KxvC05E0DIE5W0F43x4X6qCpDNqiVsvmAPKwVFcLVYZ8VGrIAbf5al+s650OTv75Tt3b MpRACrJj19hG3bBdjbFftLpeCzpOzAepXYPj+DV+W6DmumIl/tk9igrMzSEj4yxUM10Q /c6g== X-Forwarded-Encrypted: i=1; AJvYcCWrA39tnYuowz+kgECR4Meif13CTlTXjzZSmBjnKDqQUSMFC3Qf1pLfQ3f/q9yXsvTph/fPCovuVegFs1o=@vger.kernel.org X-Gm-Message-State: AOJu0YxyMzyolPcnxT5qL9UFjeeDWvnIDn5GSypn3kkWQPkZN49xQLOG LFWAy5f/pG12B+DMJuuIUVu/qfoudQqV2CZqUPCbF3IgpkaOVDWrRtkL8oNj9dTgJEJHE1ePlh3 gRYxhyVOAFy4vogAJAAhXJhYFCQ== X-Google-Smtp-Source: AGHT+IFZZkR3EHzAuwDLGLqwlWpCEXkfdxOzIJ62kCTDCDlqRRmoO9WwL9T3zPcvsxiE3ZLQSfbzaecUVDglNeDFKw== X-Received: from pjyd16.prod.google.com ([2002:a17:90a:dfd0:b0:34c:3862:5ac1]) (user=joonwonkang job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:4b28:b0:2a0:b06d:1575 with SMTP id d9443c01a7336-2a2f2a47e83mr79943535ad.51.1766401002697; Mon, 22 Dec 2025 02:56:42 -0800 (PST) Date: Mon, 22 Dec 2025 10:56:37 +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.52.0.322.g1dd061c0dc-goog Message-ID: <20251222105640.1097766-1-joonwonkang@google.com> Subject: Re: [PATCH] mailbox: Allow NULL message sending From: Joonwon Kang To: jassisinghbrar@gmail.com Cc: jonathanh@nvidia.com, joonwonkang@google.com, linux-kernel@vger.kernel.org, sudeep.holla@arm.com, thierry.reding@gmail.com, lee@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > On Mon, Dec 8, 2025 at 12:51=E2=80=AFAM Joonwon Kang wrote: > > > > On Wed, Dec 3, 2025 at 11:57=E2=80=AFPM Joonwon Kang wrote: > > > > > > > > On Tue, Nov 25, 2025 at 11:00=E2=80=AFPM Joonwon Kang wrote: > > > > > > > > > > > > Clients may want to send interrupt only without any useful mess= age > > > > > > involved. Since the current mailbox framework does not allow NU= LL > > > > > > message sending(although it allows receiving it), the clients s= hould > > > > > > allocate a dummy message buffer and pretend sending it. Besides= , if > > > > > > the mailbox controller calls `mbox_chan_txdone()` when the clie= nt > > > > > > drivers happen to send NULL message anyway, it will result in u= nexpected > > > > > > results by making the tx status messed up. This commit lifts th= e > > > > > > limitation and allows the clients to send interrupt only withou= t any > > > > > > message buffer allocated. > > > > > > > > > > > Interrupts without data messages are called 'doorbells' and we al= ready > > > > > support them. > > > > > thanks > > > > > > > > I am not sure if it is already supported. Let me draw two cases whi= ch imply > > > > that it is not supported. If the cases make sense, could you recons= ider 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 m= ailbox > > > > 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 t= his info > > in the API doc. So, now I believe that Case 2 could be seen as a hypoth= etical > > 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 wa= y for a > > client to know that the sending is really done or not. Even though a co= ntroller > > driver(I mean any typical controller, not a specific controller) calls > > `mbox_chan_txdone()` after receiving the corresponding ACK interrupt fr= om the > > remote to the previously sent NULL message, the client will be blocking= not > > knowing the sending is done. > > > For non-data channels (doorbells), the driver may expect the doorbell > info at runtime > via 'mssg'. If it doesn't, the clients send '0' or any arbitrary > non-null value which remains > unused by anyone. By "the driver", I believe that you meant the "controller" driver. If so, y= es the controller driver may or, more importantly, may **not** expect data via `mssg` as you clarified earlier: "A controller driver is supposed to either expect data or not, but not both". Also, I think it is the controller drive= r's responsibility to check if the `mssg` is NULL or not when it needs it, and = the mailbox "framework" should treat the data/message just as blackbox. In othe= r words, the framework should not enforce that any `mssg` to be sent should b= e non-NULL. Currently, clients should send the unused data even when no data = is expected or should unconditionally believe that the tx is done and not use blocking mode. This limitation could be lifted by this patch. > Maybe the api can define some MAILBOX_NULL_DATA integer that > can be used instead because the controller driver anyway doesn't need it. I guess you suggested an alternative here. If we add such integer to the cl= ient API, however, it will be a big change to the clients since now they should = be aware of the additional contract on the new integer when sending a doorbell= : they should go with `mbox_send_message(.*, MAILBOX_NULL_DATA)`. Instead, it will be better if clients could just call `mbox_send_message(.*, NULL)` wit= hout having that additional API requirement. Or if you meant instead to add the new integer but hide it from the clients= , I think I can upload another patch for that, but it may be equivalent to th= e solution in this patch. Could you help me understand the benefit your alternative has over this patch, if you meant this direction? > If/when the doorbell is rung is upto the controller - it may be just > setting a bit or observing > a status bit for the remote or whatever. The driver must say tx_done() > appropriately. If you meant here that the doorbell sending status is assumed to be checked only by polling, it does not sound generic enough to me. If a device suppor= ts ACK "interrupt" for the doorbell, I think that the mailbox framework should support it since the mailbox API already claims to support both IRQ and pol= ling for tx done: TXDONE_BY_IRQ and TXDONE_BY_POLL. > Again, it will help if we talk about the controller you have in mind exac= tly. Sorry that I am working on company private mailbox controller drivers which have not been upstreamed. What I can say is that the mailbox devices suppor= t TXDONE_BY_IRQ, not TXDONE_BY_POLL, and is to send doorbell. Since NULL mess= age sending is currently not supported on the framework, we may have to enforce clients to send unused non-NULL data, which is not practically possible sin= ce the clients are out of our control, or ignore the ACK interrupt entirely an= d enforce clients not to use blocking mode, which is also not practically possible and not good for system stability. I believe the case of TXDONE_BY= _IRQ + doorbell is generic enough, not exceptional, and should be supported on t= he current mailbox framework. If `mbox_send_message(.*, NULL)` just works out,= the problems will be resolved. Thanks!