From: sashiko-bot@kernel.org
To: "Sai Sree Kartheek Adivi" <s-adivi@ti.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org,
vkoul@kernel.org, Frank.Li@kernel.org, dmaengine@vger.kernel.org
Subject: Re: [PATCH v10 15/19] dmaengine: ti: k3-psil-am62l: Add AM62Lx PSIL and PDMA data
Date: Mon, 28 Sep 2026 03:18:05 +0000 [thread overview]
Message-ID: <20260928031806.505D71F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260928025749.1055383-16-s-adivi@ti.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] ti: k3-psil: Data race when reading/writing shared static endpoint configuration
- [Low] ti: k3-psil: Misleading error log prints channel ID instead of thread ID
--
commit fa7e3efdc8ec449e5c46f7824fe82e5b4d465743
Author: Sai Sree Kartheek Adivi <s-adivi@ti.com>
Subject: dmaengine: ti: k3-psil-am62l: Add AM62Lx PSIL and PDMA data
This commit adds PSIL and PDMA data for the AM62Lx SoC. It also introduces
a new PSIL endpoint type for multiple selectable FIFOs along with a new
fifo_id field.
> diff --git a/drivers/dma/ti/k3-psil.c b/drivers/dma/ti/k3-psil.c
> index c4b6f0df46861..153ed5fc79e53 100644
> --- a/drivers/dma/ti/k3-psil.c
> +++ b/drivers/dma/ti/k3-psil.c
> @@ -71,12 +72,68 @@ struct psil_endpoint_config *psil_get_ep_config(u32 thread_id)
> }
> EXPORT_SYMBOL_GPL(psil_get_ep_config);
>
> +struct psil_endpoint_config *psil_get_ep_config_by_id(u32 channel_id,
> + bool is_pktdma,
> + u32 *thread_id,
> + bool *dev_to_mem)
> +{
> + int i;
> +
> + mutex_lock(&ep_map_mutex);
[ ... ]
> + if (soc_ep_map->src) {
> + for (i = 0; i < soc_ep_map->src_count; i++) {
> + struct psil_ep *ep = &soc_ep_map->src[i];
> +
> + if (ep->ep_config.mapped_channel_id != (s16)channel_id)
> + continue;
> + if ((bool)ep->ep_config.pkt_mode != is_pktdma)
> + continue;
[Severity: Medium]
Could this iteration cause a data race?
This loop reads fields from the shared ep_config struct while holding
ep_map_mutex. However, in psil_set_new_ep_config(), the exact same
ep_config fields are mutated locklessly via:
memcpy(dst_ep_config, ep_config, sizeof(*dst_ep_config));
Since this iteration reads fields inside ep_config while the memcpy()
overwrites them locklessly, a race condition appears to exist that could
lead to torn reads of endpoint configurations like mapped_channel_id or
the pkt_mode bitfield.
[ ... ]
> @@ -90,9 +147,34 @@ int psil_set_new_ep_config(struct device *dev, const char *name,
> index, &dma_spec))
> return -ENOENT;
>
> - thread_id = dma_spec.args[0];
> + if (of_device_is_compatible(dma_spec.np, "ti,am62l-dmss-pktdma")) {
> + bool dev_to_mem;
> +
> + if (dma_spec.args_count < 1) {
> + of_node_put(dma_spec.np);
> + return -EINVAL;
> + }
>
> - dst_ep_config = psil_get_ep_config(thread_id);
> + thread_id = dma_spec.args[0];
> + dst_ep_config = psil_get_ep_config_by_id(dma_spec.args[0],
> + true,
> + &thread_id, &dev_to_mem);
> + } else if (of_device_is_compatible(dma_spec.np, "ti,am62l-dmss-bcdma")) {
> + bool dev_to_mem;
> +
> + if (dma_spec.args_count < 3) {
> + of_node_put(dma_spec.np);
> + return -EINVAL;
> + }
> +
> + thread_id = dma_spec.args[2];
> + dst_ep_config = psil_get_ep_config_by_id(dma_spec.args[2],
> + false,
> + &thread_id, &dev_to_mem);
> + } else {
> + thread_id = dma_spec.args[0];
> + dst_ep_config = psil_get_ep_config(thread_id);
> + }
> if (IS_ERR(dst_ep_config)) {
> pr_err("PSIL: thread ID 0x%04x not defined in map\n",
> thread_id);
[Severity: Low]
Is this error message misleading?
If psil_get_ep_config_by_id() fails to find a matching channel for the
ti,am62l-dmss-pktdma or ti,am62l-dmss-bcdma bindings, it returns an error
pointer without modifying the thread_id variable.
At this point, the thread_id variable still holds the raw channel ID
extracted from the device tree (such as dma_spec.args[0] or
dma_spec.args[2]). Printing it as "PSIL: thread ID 0x%04x not defined in
map" displays the channel ID as if it were a thread ID, which could cause
confusion during device tree debugging.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928025749.1055383-1-s-adivi@ti.com?part=15
next prev parent reply other threads:[~2026-09-28 3:18 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 2:56 [PATCH v10 00/19] dmaengine: ti: Add support for BCDMA v2 and PKTDMA v2 Sai Sree Kartheek Adivi
2026-09-28 2:56 ` [PATCH v10 01/19] dmaengine: ti: k3-udma: Fix sporadic crash on AM62x Sai Sree Kartheek Adivi
2026-09-28 8:39 ` Vignesh Raghavendra
2026-09-28 2:56 ` [PATCH v10 02/19] dmaengine: ti: k3-udma: move macros to header file Sai Sree Kartheek Adivi
2026-09-28 2:56 ` [PATCH v10 03/19] dmaengine: ti: k3-udma: move structs and enums " Sai Sree Kartheek Adivi
2026-09-28 2:56 ` [PATCH v10 04/19] dmaengine: ti: k3-udma: move static inline helper functions " Sai Sree Kartheek Adivi
2026-09-28 3:12 ` sashiko-bot
2026-09-28 2:56 ` [PATCH v10 05/19] dmaengine: ti: k3-udma: move descriptor management to k3-udma-common.c Sai Sree Kartheek Adivi
2026-09-28 8:39 ` Vignesh Raghavendra
2026-09-28 2:56 ` [PATCH v10 06/19] dmaengine: ti: k3-udma: move ring management functions " Sai Sree Kartheek Adivi
2026-09-28 2:56 ` [PATCH v10 07/19] dmaengine: ti: k3-udma: Add variant-specific function pointers to udma_dev Sai Sree Kartheek Adivi
2026-09-28 8:39 ` Vignesh Raghavendra
2026-09-28 2:56 ` [PATCH v10 08/19] dmaengine: ti: k3-udma: move udma utility functions to k3-udma-common.c Sai Sree Kartheek Adivi
2026-09-28 8:39 ` Vignesh Raghavendra
2026-09-28 2:56 ` [PATCH v10 09/19] dmaengine: ti: k3-udma: move resource management " Sai Sree Kartheek Adivi
2026-09-28 2:56 ` [PATCH v10 10/19] dmaengine: ti: k3-udma: refactor resource setup functions Sai Sree Kartheek Adivi
2026-09-28 8:39 ` Vignesh Raghavendra
2026-09-28 2:56 ` [PATCH v10 11/19] dmaengine: ti: k3-udma: move inclusion of k3-udma-private.c to k3-udma-common.c Sai Sree Kartheek Adivi
2026-09-28 3:13 ` sashiko-bot
2026-09-28 2:56 ` [PATCH v10 12/19] drivers: soc: ti: k3-ringacc: handle absence of tisci Sai Sree Kartheek Adivi
2026-09-28 3:15 ` sashiko-bot
2026-09-28 8:39 ` Vignesh Raghavendra
2026-09-28 2:56 ` [PATCH v10 13/19] dt-bindings: dma: ti: Add K3 BCDMA V2 Sai Sree Kartheek Adivi
2026-09-28 2:56 ` [PATCH v10 14/19] dt-bindings: dma: ti: Add K3 PKTDMA V2 Sai Sree Kartheek Adivi
2026-09-30 10:22 ` Krzysztof Kozlowski
2026-09-28 2:56 ` [PATCH v10 15/19] dmaengine: ti: k3-psil-am62l: Add AM62Lx PSIL and PDMA data Sai Sree Kartheek Adivi
2026-09-28 3:18 ` sashiko-bot [this message]
2026-09-28 8:39 ` Vignesh Raghavendra
2026-09-28 2:56 ` [PATCH v10 16/19] dmaengine: ti: k3-udma-v2: New driver for K3 BCDMA_V2 Sai Sree Kartheek Adivi
2026-09-28 3:26 ` sashiko-bot
2026-09-28 8:39 ` Vignesh Raghavendra
2026-09-28 2:56 ` [PATCH v10 17/19] dmaengine: ti: k3-udma-v2: Add support for PKTDMA V2 Sai Sree Kartheek Adivi
2026-09-28 3:21 ` sashiko-bot
2026-09-28 8:39 ` Vignesh Raghavendra
2026-10-01 7:17 ` Sai Sree Kartheek Adivi
2026-09-28 2:56 ` [PATCH v10 18/19] dmaengine: ti: k3-udma-v2: Update glue layer to support " Sai Sree Kartheek Adivi
2026-09-28 3:17 ` sashiko-bot
2026-09-28 2:56 ` [PATCH v10 19/19] dmaengine: ti: k3-udma: Validate resource ID and fix logging in reservation Sai Sree Kartheek Adivi
2026-09-28 8:39 ` Vignesh Raghavendra
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=20260928031806.505D71F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=robh@kernel.org \
--cc=s-adivi@ti.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.