Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/2194272/?format=api
{ "id": 2194272, "url": "http://patchwork.ozlabs.org/api/patches/2194272/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-tegra/patch/20260207200128.v2.1.I600d04c0553f5c5ba39c2f92201da313aedfe746@changeid/", "project": { "id": 21, "url": "http://patchwork.ozlabs.org/api/projects/21/?format=api", "name": "Linux Tegra Development", "link_name": "linux-tegra", "list_id": "linux-tegra.vger.kernel.org", "list_email": "linux-tegra@vger.kernel.org", "web_url": null, "scm_url": null, "webscm_url": null, "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<20260207200128.v2.1.I600d04c0553f5c5ba39c2f92201da313aedfe746@changeid>", "list_archive_url": null, "date": "2026-02-08T04:01:23", "name": "[v2,01/15] mailbox: Deprecate NULL mbox messages; Introduce mbox_ring_doorbell()", "commit_ref": null, "pull_url": null, "state": "new", "archived": false, "hash": "1f1c2a7f5efc899af2b938ea99afd584bc3bc293", "submitter": { "id": 9763, "url": "http://patchwork.ozlabs.org/api/people/9763/?format=api", "name": "Douglas Anderson", "email": "dianders@chromium.org" }, "delegate": null, "mbox": "http://patchwork.ozlabs.org/project/linux-tegra/patch/20260207200128.v2.1.I600d04c0553f5c5ba39c2f92201da313aedfe746@changeid/mbox/", "series": [ { "id": 491407, "url": "http://patchwork.ozlabs.org/api/series/491407/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-tegra/list/?series=491407", "date": "2026-02-08T04:01:22", "name": "mailbox: Stop sending NULL mailbox messages", "version": 2, "mbox": "http://patchwork.ozlabs.org/series/491407/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/2194272/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/2194272/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "\n <linux-tegra+bounces-11851-incoming=patchwork.ozlabs.org@vger.kernel.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "linux-tegra@vger.kernel.org" ], "Delivered-To": "patchwork-incoming@legolas.ozlabs.org", "Authentication-Results": [ "legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256\n header.s=google header.b=ltDvnGtR;\n\tdkim-atps=neutral", "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-tegra+bounces-11851-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)", "smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org\n header.b=\"ltDvnGtR\"", "smtp.subspace.kernel.org;\n arc=none smtp.client-ip=74.125.82.42", "smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=chromium.org", "smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=chromium.org" ], "Received": [ "from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4f7vNS2t8nz1xvW\n\tfor <incoming@patchwork.ozlabs.org>; Sun, 08 Feb 2026 15:04:40 +1100 (AEDT)", "from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 2E927302EE93\n\tfor <incoming@patchwork.ozlabs.org>; Sun, 8 Feb 2026 04:04:08 +0000 (UTC)", "from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 157202C237E;\n\tSun, 8 Feb 2026 04:04:08 +0000 (UTC)", "from mail-dl1-f42.google.com (mail-dl1-f42.google.com\n [74.125.82.42])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id AD2C921A92F\n\tfor <linux-tegra@vger.kernel.org>; Sun, 8 Feb 2026 04:04:07 +0000 (UTC)", "by mail-dl1-f42.google.com with SMTP id\n a92af1059eb24-12460a7caa2so2239956c88.1\n for <linux-tegra@vger.kernel.org>;\n Sat, 07 Feb 2026 20:04:07 -0800 (PST)", "from dianders.sjc.corp.google.com\n ([2a00:79e0:2e7c:8:6d43:22d7:40eb:81e6])\n by smtp.gmail.com with ESMTPSA id\n a92af1059eb24-127041e61b9sm7085064c88.8.2026.02.07.20.04.02\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Sat, 07 Feb 2026 20:04:03 -0800 (PST)" ], "ARC-Seal": "i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1770523447; cv=none;\n b=H7+VPnRoTtgRz4d33MtvAzSkJEoT+kMvRj7mkj9S5bKG73y9BUe4f/XATCJyL8puKgid1n8X6voQ/1gB0OIPcu0oWB6NVa+rfGxq2pV0XUs6YHkDW2pKyg48Vjy+Mno9c7gii+i5hfaQWPc1h6y1s61Yg/IHFzMcJchQnndbXy0=", "ARC-Message-Signature": "i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1770523447; c=relaxed/simple;\n\tbh=6sWk+ZD5EZZpFdZwa80I6qB0RSa/sFczAV6WHYqa1ag=;\n\th=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:\n\t MIME-Version;\n b=WywVnjWhLoHE2AKd2nF98CK+0MmrJH8N2PW+bEy8i8EDgO4O4Al4NMG7oLcN6QhZPtpGrDytbtSUx/hOu5/AR0zybQauxKIwq6mM1cP7Swj9qP++3WF3XV/3FJvbS04W4v/jexyXiGVvlnBD5iQgZmYpDTYFbELs1BIXEP6OGDo=", "ARC-Authentication-Results": "i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=chromium.org;\n spf=pass smtp.mailfrom=chromium.org;\n dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org\n header.b=ltDvnGtR; arc=none smtp.client-ip=74.125.82.42", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=chromium.org; s=google; t=1770523447; x=1771128247;\n darn=vger.kernel.org;\n h=content-transfer-encoding:mime-version:references:in-reply-to\n :message-id:date:subject:cc:to:from:from:to:cc:subject:date\n :message-id:reply-to;\n bh=U37aKUtc6RlOePvT1hsucle0pebLyklaSQDosLHQp6Q=;\n b=ltDvnGtRcGf5B+cxKtuAB/QHl4Pk1JDGGi39lkhneTUggKtjbehjd67CXEPog5qFTE\n 0X5avq3gXUJrUfruBap9PA9l7xrLb52SeRq+/CcBMhH0g0oy/+xdg6LkMennMGeiwURj\n xULNrRZOzztcJw38ljmhCY1NzTxlfYHTencZk=", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1770523447; x=1771128247;\n h=content-transfer-encoding:mime-version:references:in-reply-to\n :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=U37aKUtc6RlOePvT1hsucle0pebLyklaSQDosLHQp6Q=;\n b=LvJZ11+N+JqnDYL7W0znDam9XQP79FzQrrLrwoMEsC5m1ll1wywXesKpjleG/AMLMw\n s6F2t/X0XVXNW1fYP0Db9OgfNPGCm8CYPCQpCkDCrR1fFCc/CvTro3v87dGh6WeAWXba\n U5FZ9OUGswANGK4dcaLtJf1mIbeZP0fEwiWFtnuR2GBhutu8cEtrK1k49mOFtbWepmIG\n GvKm4taMSy4SyLtnTpp+G4Q3sBA6ntc+bH9bgkSfcxiNZ3kDJQKQg4//FK3V7/NjcHUN\n BYLR7ncGc/lU73OUcZ5iCS55za+z7uVovOwIdlWQ3L5joXYU7O9nWo/G9yD9KGojZEi3\n mPUw==", "X-Forwarded-Encrypted": "i=1;\n AJvYcCW9UFUopOOiGDW3dvFPVNFqVP//Uu2E5PZ0aXzauufEVofO1f1JZ2dUxVPXmnTCrrrPh7tSao13H4lMgw==@vger.kernel.org", "X-Gm-Message-State": "AOJu0YwF3QyhOyX9DKm9MXkW9ElNzRXifbH8KLlwcEGvPDp6B71b0RO6\n\tIhWPdMCDMZNMtYLtNzNHgUxGUHsg4hMP4NGXTrGVKvLkUynaZd24O0/qnbLVtbZ5RW5zGrKCzwa\n\tuUeA=", "X-Gm-Gg": "AZuq6aKgc9dEOVxx/JnQdIF6oRwL/MBbNoalS9l6/cdSH0RqTQY8xtEa93jumWaJBGh\n\tBZjluEtiFSxJE8l5WXiWvKdpS10RqsTUq1p62iofPBhshawJ0ZpvgCyY2zXPUzZ00rAWs3/Mo0y\n\t4xQHpcBRVEYGr7XeNA7at9faUEZVQ3PsWlKMoUKe2FEwkYyLAkNg9BzFyh186iPSG64FQF1Zdzr\n\thI4f+hdO68QeiZElT3ZcBUVTsjqPIMQfvoZI06A1OYRiK1/QqsrFmuzTmzf/2dUOae9hvzldA1h\n\ttUjCbFMU8svSg6+Q4+EIgHwNxhl0ci7X8JL6VQ0iFc/gXhSfdxFMo7UeAn6dkqFmuI7KIMf8HHQ\n\tIDmr37Rh+rLJVshrJ8JbJ6ceB4nWQ9jH66SOUYG9+kut/spK8UA4Y/fNsXn3tOplu3sebo2Rxmh\n\tFyYXvz5wHvgzhSZVZEiTwCrI4tKREmmaTnQsNKBfIXDOXPTBORJfLkrM8szyNAy3VO4jLfnOo=", "X-Received": "by 2002:a05:7022:250e:b0:11a:2f10:fa46 with SMTP id\n a92af1059eb24-12703e569femr3754647c88.0.1770523446753;\n Sat, 07 Feb 2026 20:04:06 -0800 (PST)", "From": "Douglas Anderson <dianders@chromium.org>", "To": "jassisinghbrar@gmail.com", "Cc": "Douglas Anderson <dianders@chromium.org>,\n\tFrank.Li@nxp.com,\n\tandersson@kernel.org,\n\tarm-scmi@vger.kernel.org,\n\tcristian.marussi@arm.com,\n\tfestevam@gmail.com,\n\timx@lists.linux.dev,\n\tjay.buddhabhatti@amd.com,\n\tjonathanh@nvidia.com,\n\tkernel@pengutronix.de,\n\tkonradybcio@kernel.org,\n\tkrzk@kernel.org,\n\tlenb@kernel.org,\n\tlinux-acpi@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org,\n\tlinux-arm-msm@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org,\n\tlinux-remoteproc@vger.kernel.org,\n\tlinux-tegra@vger.kernel.org,\n\tmathieu.poirier@linaro.org,\n\tmichal.simek@amd.com,\n\tnm@ti.com,\n\trafael@kernel.org,\n\trobh@kernel.org,\n\ts.hauer@pengutronix.de,\n\tshawn.guo@linaro.org,\n\tssantosh@kernel.org,\n\tsudeep.holla@kernel.org,\n\ttglx@kernel.org,\n\tthierry.reding@gmail.com", "Subject": "[PATCH v2 01/15] mailbox: Deprecate NULL mbox messages;\n Introduce mbox_ring_doorbell()", "Date": "Sat, 7 Feb 2026 20:01:23 -0800", "Message-ID": "\n <20260207200128.v2.1.I600d04c0553f5c5ba39c2f92201da313aedfe746@changeid>", "X-Mailer": "git-send-email 2.53.0.rc2.204.g2597b5adb4-goog", "In-Reply-To": "<20260208040240.1971442-1-dianders@chromium.org>", "References": "<20260208040240.1971442-1-dianders@chromium.org>", "Precedence": "bulk", "X-Mailing-List": "linux-tegra@vger.kernel.org", "List-Id": "<linux-tegra.vger.kernel.org>", "List-Subscribe": "<mailto:linux-tegra+subscribe@vger.kernel.org>", "List-Unsubscribe": "<mailto:linux-tegra+unsubscribe@vger.kernel.org>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "8bit" }, "content": "The way the mailbox core behaves when you pass a NULL `mssg` parameter\nto mbox_send_message() is a little questionable. Specifically, the\nmailbox core stores the currently active message directly in its\n`active_req` field. In at least two places it decides that if this\nfield is `NULL` then there is no active request. That means if `mssg`\nis ever NULL it will cause the mailbox core to think is no active\nrequest. The two places where it does this are:\n\n1. When a client calls mbox_send_message(), if `active_req` is NULL\n then it will call the mailbox controller to send the new message\n even if the mailbox controller hasn't yet called mbox_chan_txdone()\n on the previous (NULL) message.\n2. The mailbox core will never call the client's `tx_done()` callback\n with a NULL message because `tx_tick()` returns early whenever the\n message is NULL.\n\nThough the above doesn't look like it was a conscious design choice,\nit does have the benefit of providing a simple way to assert an\nedge-triggered interrupt to the remote processor on the other side of\nthe mailbox. Specifically:\n\n1. Like a normal edge-triggered interrupt, if multiple edges arrive\n before the interrupt is Acked they are coalesced.\n2. Like a normal edge-triggered interrupt, as long as the receiver\n (the remote processor in this case) \"Ack\"s the interrupt _before_\n checking for work and the sender (the mailbox client in this case)\n posts the interrupt _after_ adding new work then we can always be\n certain that new work will be noticed. This assumes that the\n mailbox client and remote processor have some out-of-band way to\n communicate work and the mailbox is just being used as an\n interrupt.\n\nDoing a `git grep -A1 mbox_send_message | grep NULL` shows 14 hits in\nmainline today, but it's not 100% clear if all of those users are\nrelying on the benefits/quirks of the existing behavior.\n\nSince the current NULL `mssg` behavior is a bit questionable but has\nsome benefits, let's:\n\n1. Deprecate the NULL behavior and print a warning.\n2. Add a new mbox_ring_doorbell() function that is very similar to the\n existing NULL `mssg` case but a tad bit cleaner.\n\nThe design of the new mbox_ring_doorbell() will be to maximize\ncompatibility with the old NULL `mssg` behavior. Specifically:\n\n* We'll still pass NULL to the mailbox controller to indicate a\n doorbell.\n* Doorbells will not be queued and won't have txdone.\n* We'll call immediately into the mailbox controller when a doorbell\n is posted.\n\nWith the above, any mailbox clients that don't mix doorbells and\nnormal messages are intended to see no change in behavior when\nswitching to the new API. Using the new API, which officiall documents\nthat mbox_client_txdone() shouldn't be called for doorbells, does\nallow us to remove those calls.\n\nThere are two differences in behavior between the old sending a NULL\nmessage and the new mbox_ring_doorbell():\n\n1. If the mailbox controller returned an error when trying to send a\n NULL message, the old NULL message could have ended up being queued\n up in the core's FIFO. Now we will just return the error.\n2. If a client rings a doorbell while a non-doorbell message is in\n progress, previously NULL messages would have been \"queued\" in that\n case and now doorbells will be immediately posted.\n\nI'm hoping that nobody was relying on either of the two differences.\nIn general holding NULL messages in the mailbox core's queue has odd\nbehavior and is hard to reason about. Hopefully it's reasonable to\nassume nobody was doing this.\n\nAs mentioned above, it should be noted that it's now documented that\n\"txdone\" shouldn't be called (by both mailbox drivers and clients) for\ndoorbells. That being said, in most cases it won't hurt since the\nmailbox core will ignore the bogus \"txdone\". The only case where it's\ncritical for a mailbox controller not to call \"txdone\" for a doorbell\nis when a mailbox channel mixes normal messages and doorbells and\ncares about the txdone callback. Specifically, when you ring a\ndoorbell and immediately send a normal message, if the controller\ncalls \"txdone\" for the doorbell it could look as if the normal message\nfinished before it should have. This issue also would have happened\nwith the old NULL `mssg`, though.\n\nSigned-off-by: Douglas Anderson <dianders@chromium.org>\n---\n\nChanges in v2:\n- Instead of just documenting NULL, introduce a new function\n\n drivers/mailbox/mailbox.c | 82 +++++++++++++++++++++++++++++-\n include/linux/mailbox_client.h | 1 +\n include/linux/mailbox_controller.h | 4 +-\n 3 files changed, 85 insertions(+), 2 deletions(-)", "diff": "diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c\nindex 2acc6ec229a4..c1e7f6b1fe72 100644\n--- a/drivers/mailbox/mailbox.c\n+++ b/drivers/mailbox/mailbox.c\n@@ -161,6 +161,9 @@ EXPORT_SYMBOL_GPL(mbox_chan_received_data);\n * The controller that has IRQ for TX ACK calls this atomic API\n * to tick the TX state machine. It works only if txdone_irq\n * is set by the controller.\n+ *\n+ * Should not be called for \"doorbell\" messages (any time the message\n+ * sent was NULL).\n */\n void mbox_chan_txdone(struct mbox_chan *chan, int r)\n {\n@@ -182,6 +185,9 @@ EXPORT_SYMBOL_GPL(mbox_chan_txdone);\n * The client/protocol had received some 'ACK' packet and it notifies\n * the API that the last packet was sent successfully. This only works\n * if the controller can't sense TX-Done.\n+ *\n+ * Should not be called for \"doorbell\" messages (any time the message\n+ * sent was NULL).\n */\n void mbox_client_txdone(struct mbox_chan *chan, int r)\n {\n@@ -222,7 +228,7 @@ EXPORT_SYMBOL_GPL(mbox_client_peek_data);\n * mbox_send_message -\tFor client to submit a message to be\n *\t\t\t\tsent to the remote.\n * @chan: Mailbox channel assigned to this client.\n- * @mssg: Client specific message typecasted.\n+ * @mssg: Client specific message typecasted. Should not be NULL.\n *\n * For client to submit data to the controller destined for a remote\n * processor. If the client had set 'tx_block', the call will return\n@@ -249,6 +255,28 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)\n \tif (!chan || !chan->cl)\n \t\treturn -EINVAL;\n \n+\t/*\n+\t * The mailbox core gets confused when mbox_send_message() is called\n+\t * with NULL messages since the code directly stores messages in\n+\t * `active_req` and assumes that a NULL `active_req` means no request\n+\t * is active. This causes the core to call the mailbox controller a\n+\t * second time even if the previous message hasn't finished and also\n+\t * means the client's tx_done() callback will never be called. However,\n+\t * clients historically passed NULL anyway. Deprecate passing NULL\n+\t * here by adding a warning.\n+\t *\n+\t * Clients who don't have a message should switch to using\n+\t * mbox_ring_doorbell(), which explicitly documents the immediate\n+\t * sending of doorbells, the lack of txdone, and what happens if you\n+\t * mix doorbells and normal messages.\n+\t *\n+\t * TODO: when it's certain that all clients have transitioned, consider\n+\t * changing this to return -EINVAL.\n+\t */\n+\tif (!mssg)\n+\t\tdev_warn_once(chan->mbox->dev,\n+\t\t\t \"NULL mailbox messages are deprecated\\n\");\n+\n \tt = add_to_rbuf(chan, mssg);\n \tif (t < 0) {\n \t\tdev_err(chan->mbox->dev, \"Try increasing MBOX_TX_QUEUE_LEN\\n\");\n@@ -277,6 +305,58 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)\n }\n EXPORT_SYMBOL_GPL(mbox_send_message);\n \n+/**\n+ * mbox_ring_doorbell - Client function to ring the doorbell with no message.\n+ * @chan: Mailbox channel assigned to this client.\n+ *\n+ * Send a notification to the remote side of the mailbox but don't actually\n+ * send any data. This is typically used when the client and the remote side\n+ * of the mailbox have some other (non-mailbox) way to communicate and the\n+ * mailbox is simply used as an \"interrupt\" to notify the remote side.\n+ *\n+ * This function has a few important differences from mbox_send_message():\n+ * - There is no concept of \"txdone\" for mbox_ring_doorbell(), even if the\n+ * controller itself would be able to tell when the remote CPU saw or Acked\n+ * the doorbell.\n+ * - Because there is no concept of \"txdone\", there is no need to wait for\n+ * previous doorbells to \"finish\" before notifying the controller of another\n+ * doorbell.\n+ * - Because we never wait to notify a controller of a doorbell, there is no\n+ * queue for doorbells.\n+ *\n+ * The above properties mean that calling mbox_ring_doorbell() is the equivalent\n+ * of re-asserting an edge triggered interrupt to the remote side. If the remote\n+ * side hasn't yet \"cleared\" the interrupt this is a no-op. If the remote side\n+ * has cleared the interrupt, it will be re-asserted. Expected usage:\n+ *\n+ * This CPU:\n+ * - Update out-of-band (OOB) memory shared between this CPU and remote CPU.\n+ * - Ring doorbell.\n+ * Remote CPU:\n+ * - Clear doorbell.\n+ * - Read OOB shared memory and act on it.\n+ *\n+ * The remote CPU will always be guaranteed to notice changes, even if this CPU\n+ * updates / rings multiple times before the remote CPU has a chance to run.\n+ *\n+ * Mixing calls of mbox_ring_doorbell() and mbox_send_message() on the same\n+ * mailbox channel is allowed, assuming the mailbox controller correctly avoids\n+ * calling mbox_chan_txdone() for doorbells.\n+ *\n+ * NOTE: For compatibility reasons, doorbells are sent to the mailbox\n+ *\t controller driver by passing NULL to the mailbox controller's\n+ *\t send_data() callback.\n+ *\n+ * Return: Negative error code upon failure.\n+ */\n+int mbox_ring_doorbell(struct mbox_chan *chan)\n+{\n+\tguard(spinlock_irqsave)(&chan->lock);\n+\n+\treturn chan->mbox->ops->send_data(chan, NULL);\n+}\n+EXPORT_SYMBOL_GPL(mbox_ring_doorbell);\n+\n /**\n * mbox_flush - flush a mailbox channel\n * @chan: mailbox channel to flush\ndiff --git a/include/linux/mailbox_client.h b/include/linux/mailbox_client.h\nindex c6eea9afb943..e3fc11e42c58 100644\n--- a/include/linux/mailbox_client.h\n+++ b/include/linux/mailbox_client.h\n@@ -42,6 +42,7 @@ struct mbox_chan *mbox_request_channel_byname(struct mbox_client *cl,\n \t\t\t\t\t const char *name);\n struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index);\n int mbox_send_message(struct mbox_chan *chan, void *mssg);\n+int mbox_ring_doorbell(struct mbox_chan *chan);\n int mbox_flush(struct mbox_chan *chan, unsigned long timeout);\n void mbox_client_txdone(struct mbox_chan *chan, int r); /* atomic */\n bool mbox_client_peek_data(struct mbox_chan *chan); /* atomic */\ndiff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h\nindex 80a427c7ca29..36648fa7b6f3 100644\n--- a/include/linux/mailbox_controller.h\n+++ b/include/linux/mailbox_controller.h\n@@ -19,7 +19,9 @@ struct mbox_chan;\n *\t\tif the remote hasn't yet read the last data sent. Actual\n *\t\ttransmission of data is reported by the controller via\n *\t\tmbox_chan_txdone (if it has some TX ACK irq). It must not\n- *\t\tsleep.\n+ *\t\tsleep. Will be passed NULL data for doorbell-only messages.\n+ *\t\tNote that doorbell messages are always sent immediately with\n+ *\t\tno queuing. mbox_chan_txdone() shouldn't be called on doorbells.\n * @flush:\tCalled when a client requests transmissions to be blocking but\n *\t\tthe context doesn't allow sleeping. Typically the controller\n *\t\twill implement a busy loop waiting for the data to flush out.\n", "prefixes": [ "v2", "01/15" ] }