From: Andrew Davis <afd@ti.com>
To: Beleswar Padhi <b-padhi@ti.com>, <nm@ti.com>, <kristo@kernel.org>,
<ssantosh@kernel.org>, <vigneshr@ti.com>, <u-kumar1@ti.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 11/22] firmware: ti_sci: Use rx_message as message receive buffer
Date: Wed, 30 Sep 2026 13:52:17 -0500 [thread overview]
Message-ID: <9785e0e2-2bc2-412f-8ba7-d7cc0b5a694e@ti.com> (raw)
In-Reply-To: <20260930160607.2674980-12-b-padhi@ti.com>
On 9/30/26 11:05 AM, Beleswar Padhi wrote:
> From: Andrew Davis <afd@ti.com>
>
> Previously we allocated a message buffer big enough for the largest
> message we could receive for every message we could have concurrently
> in flight. Now have the rx_message buffer during the whole xfer process
s/Now have/Now that we have
> we can use that as our message receive buffer. This removes an extra copy
> and the amount of memory we need to pre-allocate.
>
> Note: rx_buf now points to the caller's on-stack response buffer. If
> the system firmware replies after ti_sci_do_xfer() has timed out, the
> rx callback can race with the caller returning and write into a stale
> stack frame. A reply that arrives after the timeout means the system
To add, the RX callback checks that the message is still expected
and returns safely if not. After a timeout the ti_sci_do_xfer()
function marks the message as no longer expected, before the stack
frame goes out of scope. The only way this can be an issue is if
the RX callback happens exactly after the timeout and is able
to get past the check before we set it, and then also not finish
the memcpy until after we return from setting that expected check.
We could probably still solve that with some additional locking, but
in practice this exact sequence is never going to happen. And the only
time a message timeouts is when the TI-SCI firmware has crashed, so
your system is already borked.
Andrew
> firmware is not responding within its specified bounds, after which the
> system cannot be expected to operate correctly anyway, so this is not
> handled.
>
> Signed-off-by: Andrew Davis <afd@ti.com>
> Co-developed-by: Beleswar Padhi <b-padhi@ti.com>
> Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
> ---
> v2: Changelog:
> 1. None to this patch.
>
> Link to v1:
> https://lore.kernel.org/all/20260929201746.4078803-12-b-padhi@ti.com/
>
> drivers/firmware/ti_sci.c | 21 +++++----------------
> 1 file changed, 5 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> index 6ed67160c6a7f..fef7028d40e39 100644
> --- a/drivers/firmware/ti_sci.c
> +++ b/drivers/firmware/ti_sci.c
> @@ -45,14 +45,12 @@ static DEFINE_MUTEX(ti_sci_list_mutex);
> * @tx_message: Transmit message
> * @rx_buf: Pointer to store received message
> * @rx_len: Receive message length
> - * @xfer_buf: Preallocated buffer to store receive message
> * @done: completion event
> */
> struct ti_sci_xfer {
> struct ti_msgmgr_message tx_message;
> void *rx_buf;
> u8 rx_len;
> - u8 *xfer_buf;
> struct completion done;
> };
>
> @@ -287,7 +285,7 @@ static void ti_sci_rx_callback(struct mbox_client *cl, void *m)
>
> ti_sci_dump_header_dbg(dev, hdr);
> /* Take a copy to the rx buffer.. */
> - memcpy(xfer->xfer_buf, mbox_msg->buf, xfer->rx_len);
> + memcpy(xfer->rx_buf, mbox_msg->buf, xfer->rx_len);
> complete(&xfer->done);
> }
>
> @@ -522,12 +520,10 @@ static inline int ti_sci_do_xfer(const struct ti_sci_handle *handle,
> * state, then ensure that the response is an ACK
> */
> if (response_expected && ret == 0) {
> - if (!ti_sci_is_response_ack(xfer->xfer_buf)) {
> + if (!ti_sci_is_response_ack(xfer->rx_buf)) {
> dev_warn(dev, "Message response not acknowledged (caller: %pS)\n",
> caller);
> ret = -ENODEV;
> - } else {
> - memcpy(xfer->rx_buf, xfer->xfer_buf, xfer->rx_len);
> }
> }
>
> @@ -3326,7 +3322,6 @@ static int ti_sci_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> const struct ti_sci_desc *desc;
> - struct ti_sci_xfer *xfer;
> struct ti_sci_info *info = NULL;
> struct ti_sci_xfers_info *minfo;
> struct mbox_client *cl;
> @@ -3380,15 +3375,9 @@ static int ti_sci_probe(struct platform_device *pdev)
> if (!minfo->xfer_alloc_table)
> return -ENOMEM;
>
> - /* Pre-initialize the buffer pointer to pre-allocated buffers */
> - for (i = 0, xfer = minfo->xfer_block; i < desc->max_msgs; i++, xfer++) {
> - xfer->xfer_buf = devm_kzalloc(dev, desc->max_msg_size,
> - GFP_KERNEL);
> - if (!xfer->xfer_buf)
> - return -ENOMEM;
> -
> - init_completion(&xfer->done);
> - }
> + /* Initialize the xfer completions */
> + for (i = 0; i < desc->max_msgs; i++)
> + init_completion(&minfo->xfer_block[i].done);
>
> ret = ti_sci_debugfs_create(pdev, info);
> if (ret)
next prev parent reply other threads:[~2026-09-30 18:53 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 16:05 [PATCH v2 00/22] Cleanup and Refactor TI-SCI driver Beleswar Padhi
2026-09-30 16:05 ` [PATCH v2 01/22] firmware: ti_sci: Move error message handling into ti_sci_get_one_xfer() Beleswar Padhi
2026-09-30 16:05 ` [PATCH v2 02/22] firmware: ti_sci: Move error message handling into ti_sci_do_xfer() Beleswar Padhi
2026-09-30 16:05 ` [PATCH v2 03/22] firmware: ti_sci: Move check for ACK " Beleswar Padhi
2026-09-30 16:05 ` [PATCH v2 04/22] firmware: ti_sci: Remove out of place RM debug messages Beleswar Padhi
2026-09-30 16:05 ` [PATCH v2 05/22] firmware: ti_sci: Name response variable resp for consistency Beleswar Padhi
2026-09-30 16:05 ` [PATCH v2 06/22] firmware: ti_sci: Handle xfer cleanup inside ti_sci_do_xfer() Beleswar Padhi
2026-09-30 16:05 ` [PATCH v2 07/22] firmware: ti_sci: Pass request struct into ti_sci_do_xfer() Beleswar Padhi
2026-09-30 16:05 ` [PATCH v2 08/22] firmware: ti_sci: Combine xfer allocation and transfer functions Beleswar Padhi
2026-09-30 16:05 ` [PATCH v2 09/22] firmware: ti_sci: Fetch info struct from handle inside ti_sci_do_xfer() Beleswar Padhi
2026-09-30 16:05 ` [PATCH v2 10/22] firmware: ti_sci: Use tx_message as message buffer directly Beleswar Padhi
2026-09-30 16:05 ` [PATCH v2 11/22] firmware: ti_sci: Use rx_message as message receive buffer Beleswar Padhi
2026-09-30 18:52 ` Andrew Davis [this message]
2026-09-30 20:17 ` Padhi, Beleswar
2026-09-30 16:05 ` [PATCH v2 12/22] firmware: ti_sci: Fix some kernel-doc references in structs Beleswar Padhi
2026-09-30 16:05 ` [PATCH v2 13/22] soc: ti: ti_sci_protocol.h: Add missing documentation for structs Beleswar Padhi
2026-09-30 16:05 ` [PATCH v2 14/22] firmware: ti_sci: Do not export reboot control Beleswar Padhi
2026-09-30 16:06 ` [PATCH v2 15/22] firmware: ti_sci: Use pmops fxn pointers in suspend/resume hooks Beleswar Padhi
2026-09-30 16:06 ` [PATCH v2 16/22] firmware: ti_sci: Move the huge ti_sci file into its own directory Beleswar Padhi
2026-09-30 19:05 ` Andrew Davis
2026-09-30 16:06 ` [PATCH v2 17/22] firmware: ti: ti_sci: Add missing includes for self-contained headers Beleswar Padhi
2026-09-30 16:06 ` [PATCH v2 18/22] firmware: ti: ti_sci_device: Move device ops into its own file Beleswar Padhi
2026-09-30 16:06 ` [PATCH v2 19/22] firmware: ti: ti_sci_clock: Move clock " Beleswar Padhi
2026-09-30 16:06 ` [PATCH v2 20/22] firmware: ti: ti_sci_pm: Move pm " Beleswar Padhi
2026-09-30 16:06 ` [PATCH v2 21/22] firmware: ti: ti_sci_rm: Move rm " Beleswar Padhi
2026-09-30 16:06 ` [PATCH v2 22/22] firmware: ti: ti_sci_proc: Move processor " Beleswar Padhi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9785e0e2-2bc2-412f-8ba7-d7cc0b5a694e@ti.com \
--to=afd@ti.com \
--cc=b-padhi@ti.com \
--cc=kristo@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nm@ti.com \
--cc=ssantosh@kernel.org \
--cc=u-kumar1@ti.com \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®