All of lore.kernel.org
 help / color / mirror / Atom feed
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 v3 2/5] remoteproc: switch exact-match drivers to wc-ioremap callbacks
Date: Fri, 29 May 2026 03:34:28 +0000	[thread overview]
Message-ID: <20260529033429.051701F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260529021637.2077602-3-ben.levinsky@amd.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The error logging in the `rproc_mem_entry_ioremap_wc` helper uses the `%pa` format specifier for a `dma_addr_t` pointer instead of `%pad`.
--

commit 06feb3b32004ed7bd1d29e99430abd615d6b4449
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. This
covers xlnx_r5_remoteproc, rcar_rproc, st_remoteproc, stm32_rproc,
imx_rproc, and imx_dsp_rproc.

Leave the zynqmp R5 TCM callbacks alone because they also clear the
mapped memory and are therefore not exact matches for the shared
helpers.

> diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
> index 632614013dc65..a6e36a11627d7 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
[ ... ]
> @@ -237,8 +208,8 @@ static int stm32_rproc_prepare(struct rproc *rproc)
>  			mem = rproc_mem_entry_init(dev, NULL,
>  						   (dma_addr_t)res.start,
>  						   resource_size(&res), da,
> -						   stm32_rproc_mem_alloc,
> -						   stm32_rproc_mem_release,
> +						   rproc_mem_entry_ioremap_wc,

[Severity: Medium]
Does replacing the stm32 callback with the common helper regress its error
logging?

The original stm32_rproc_mem_alloc() function correctly used %pad for
mem->dma:

    dev_err(dev, "Unable to map memory region: %pad+0x%zx\n",
            &mem->dma, mem->len);

However, the new rproc_mem_entry_ioremap_wc() helper uses %pa:

    dev_err(&rproc->dev, "Unable to map memory region: %pa+%zx\n",
            &mem->dma, mem->len);

Since mem->dma is a dma_addr_t, and %pa expects a phys_addr_t *, could this
result in reading the wrong number of bytes on platforms where
sizeof(dma_addr_t) != sizeof(phys_addr_t)?

This could combine the dma and adjacent len fields, printing a garbage
address in the log.

> +						   rproc_mem_entry_iounmap,
>  						   "%.*s", strchrnul(res.name, '@') - res.name,
>  						   res.name);
>  			if (mem)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260529021637.2077602-1-ben.levinsky@amd.com?part=2

  reply	other threads:[~2026-05-29  3:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-29  2:16 [PATCH v3 0/5] remoteproc: cleanup shared carveout and resource-table helpers Ben Levinsky
2026-05-29  2:16 ` [PATCH v3 1/5] remoteproc: add common wc-ioremap carveout callbacks Ben Levinsky
2026-05-29  2:51   ` sashiko-bot
2026-05-29  2:16 ` [PATCH v3 2/5] remoteproc: switch exact-match drivers to wc-ioremap callbacks Ben Levinsky
2026-05-29  3:34   ` sashiko-bot [this message]
2026-05-29  2:16 ` [PATCH v3 3/5] remoteproc: mark wc-ioremap carveouts as iomem Ben Levinsky
2026-05-29  4:16   ` sashiko-bot
2026-05-29  2:16 ` [PATCH v3 4/5] remoteproc: add helper for optional ELF resource tables Ben Levinsky
2026-05-29  4:31   ` sashiko-bot
2026-05-29  2:16 ` [PATCH v3 5/5] remoteproc: switch drivers to optional resource-table helper Ben Levinsky
2026-05-29  4:42   ` sashiko-bot
2026-05-29  8:42 ` [PATCH v3 0/5] remoteproc: cleanup shared carveout and resource-table helpers Wolfram Sang
2026-06-01 14:42 ` Mathieu Poirier
2026-06-06  3:43   ` Peng Fan

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=20260529033429.051701F000E9@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.