From: sashiko-bot@kernel.org
To: "Ben Levinsky" <ben.levinsky@amd.com>
Cc: Frank.Li@kernel.org, imx@lists.linux.dev,
wsa+renesas@sang-engineering.com
Subject: Re: [PATCH 2/4] remoteproc: switch exact-match drivers to wc-ioremap callbacks
Date: Wed, 13 May 2026 01:33:23 +0000 [thread overview]
Message-ID: <20260513013324.4F59CC2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260511211841.284809-3-ben.levinsky@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Implicit and undocumented behavioral change in memory access semantics, and introduced inconsistency.
--
commit 33b97865cf4d72ce26fd26e8b0209b38daaf1222
Author: Ben Levinsky <ben.levinsky@amd.com>
remoteproc: switch exact-match drivers to wc-ioremap callbacks
Replace the exact-match carveout map and unmap callbacks in the
existing remoteproc drivers with the common wc-ioremap helpers. Leave
the zynqmp R5 TCM callbacks alone because they also clear the mapped
memory and are not exact matches.
> diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
> index 008741af9f11c..2d9f14fbef1da 100644
> --- a/drivers/remoteproc/imx_dsp_rproc.c
> +++ b/drivers/remoteproc/imx_dsp_rproc.c
[ ... ]
> @@ -700,8 +674,10 @@ static int imx_dsp_rproc_add_carveout(struct imx_dsp_rproc *priv)
>
> /* Register memory region */
> mem = rproc_mem_entry_init(dev, NULL, (dma_addr_t)att->sa,
> - att->size, da, imx_dsp_rproc_mem_alloc,
> - imx_dsp_rproc_mem_release, "dsp_mem");
> + att->size, da,
> + rproc_mem_entry_ioremap_wc,
> + rproc_mem_entry_iounmap,
> + "dsp_mem");
Does replacing the custom callbacks with rproc_mem_entry_ioremap_wc()
unintentionally alter the memory access semantics for these drivers?
The new rproc_mem_entry_ioremap_wc() helper explicitly sets
mem->is_iomem = true. The previous custom callbacks like
imx_dsp_rproc_mem_alloc() called ioremap_wc() but left mem->is_iomem as
false.
Setting is_iomem = true causes the ELF loader and coredump routines to
switch from standard memcpy() and memset() to I/O accessors like
memcpy_toio() and memset_io().
While this is likely safer for I/O mapped memory, this behavioral change
does not appear to be documented in the commit message. Should the commit
message document this shift in memory access semantics?
> Leave the zynqmp R5 TCM callbacks alone because they also clear the mapped
> memory and are not exact matches.
By leaving the ZynqMP R5 TCM callbacks untouched, does this create an
inconsistency in how the remoteproc framework handles I/O mapped memory?
The ZynqMP R5 TCM callbacks will continue to map memory using ioremap_wc()
without setting is_iomem = true. Would it be better to update the ZynqMP
callbacks to also set is_iomem so the framework accesses I/O memory
consistently across all drivers?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260511211841.284809-1-ben.levinsky@amd.com?part=2
next prev parent reply other threads:[~2026-05-13 1:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 21:18 [PATCH 0/4] remoteproc: cleanup shared carveout and resource-table helpers Ben Levinsky
2026-05-11 21:18 ` [PATCH 1/4] remoteproc: add common wc-ioremap carveout callbacks Ben Levinsky
2026-05-12 9:44 ` Arnaud POULIQUEN
[not found] ` <DM4PR12MB64482037D67096393D4668CE83392@DM4PR12MB6448.namprd12.prod.outlook.com>
2026-05-12 17:15 ` Ben Levinsky
2026-05-11 21:18 ` [PATCH 2/4] remoteproc: switch exact-match drivers to wc-ioremap callbacks Ben Levinsky
2026-05-12 7:06 ` Geert Uytterhoeven
2026-05-13 1:33 ` sashiko-bot [this message]
2026-05-11 21:18 ` [PATCH 3/4] remoteproc: add helper for optional ELF resource tables Ben Levinsky
2026-05-12 7:55 ` Daniel Baluta
2026-05-12 9:22 ` Arnaud POULIQUEN
2026-05-12 14:53 ` Shah, Tanmay
[not found] ` <DM4PR12MB6448B1E51D58F3F8B11171F683392@DM4PR12MB6448.namprd12.prod.outlook.com>
2026-05-12 17:19 ` Ben Levinsky
2026-05-13 6:30 ` Daniel Baluta
2026-05-13 7:37 ` Arnaud POULIQUEN
2026-05-13 1:42 ` sashiko-bot
2026-05-11 21:18 ` [PATCH 4/4] remoteproc: switch drivers to optional resource-table helper Ben Levinsky
2026-05-12 7:07 ` Geert Uytterhoeven
2026-05-13 2:48 ` sashiko-bot
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=20260513013324.4F59CC2BCB0@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=ben.levinsky@amd.com \
--cc=imx@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wsa+renesas@sang-engineering.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 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.