From: Peng Fan <peng.fan@oss.nxp.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Ben Levinsky <ben.levinsky@amd.com>,
arnaud.pouliquen@foss.st.com, daniel.baluta@nxp.com,
Bjorn Andersson <andersson@kernel.org>,
linux-remoteproc@vger.kernel.org, Frank Li <Frank.Li@nxp.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Magnus Damm <magnus.damm@gmail.com>,
Patrice Chotard <patrice.chotard@foss.st.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Tanmay Shah <tanmay.shah@amd.com>,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH v3 0/5] remoteproc: cleanup shared carveout and resource-table helpers
Date: Sat, 6 Jun 2026 11:43:19 +0800 [thread overview]
Message-ID: <aiOXV2k6/4zMh4ST@shlinux89> (raw)
In-Reply-To: <ah2aVdlsLqy9aeHP@p14s>
On Mon, Jun 01, 2026 at 08:42:29AM -0600, Mathieu Poirier wrote:
>Good morning,
>
>On Thu, May 28, 2026 at 07:16:32PM -0700, Ben Levinsky wrote:
>> This series is a preparatory remoteproc cleanup split out from review of
>> the AMD BRAM-based remoteproc series.
>>
>> During review, there was a request to move the duplicated plain
>> ioremap_wc()/iounmap() carveout callbacks into common code and to
>> factor the "missing resource table is OK" ELF parsing path into a
>> common helper as well. There was also a request to send that cleanup as
>> its own patchset first, with the AMD BRAM series respun afterwards on
>> top once this cleanup is merged.
>>
>> This version keeps the same overall cleanup goals as v2, but reworks
>> the optional resource-table pieces based on follow-up review:
>>
>> - reshape the optional resource-table helper in patch 4 into the thin
>> parse_fw() wrapper form suggested on the thread
>> - switch the patch 5 clients over to that helper shape directly,
>> without post-helper rproc->table_ptr checks
>> - keep the driver-local parse_fw() wrappers and their existing log
>> messages and severity choices
>> - retain as much of the existing per-driver parse_fw() logic and code
>> placement as possible while moving the missing-table handling
>> through the shared helper
>>
>> This series now does that in five patches:
>>
>> 1. add common subsystem-private callbacks for the exact-match
>> wc-ioremap carveout case
>> 2. switch the in-tree exact-match users over to those callbacks
>> 3. mark carveouts mapped through the shared wc-ioremap helper as
>> iomem so the framework uses the proper I/O accessors
>> 4. add a common helper for drivers that treat a missing ELF resource
>> table as optional while keeping per-driver logging decisions local
>> 5. switch the matching in-tree drivers over to that helper while
>> keeping thin local parse_fw() wrappers
>>
>> For the carveout map/unmap cleanup, this series covers the exact-match
>> users called out in review: xlnx_r5_remoteproc, rcar_rproc,
>> st_remoteproc, stm32_rproc, imx_rproc, and imx_dsp_rproc. The zynqmp R5
>> TCM mapping path is left alone because it also clears the mapped memory
>> and is not an exact match.
>>
>> For the optional resource-table handling, this series converts
>> xlnx_r5_remoteproc, rcar_rproc, stm32_rproc, imx_rproc, and
>> imx_dsp_rproc. st_remoteproc is intentionally left unchanged because its
>> parse_fw() callback also builds carveouts and is therefore not a direct
>> match for the helper introduced here.
>>
>> Changes in v3:
>> - rework patch 4 so the optional resource-table helper matches the
>> thin-wrapper form suggested in review
>> - note that patch 4 still triggers a checkpatch --strict warning for
>> the flow-control macro form, but that implementation follows the
>> maintainer's review suggestion for the thin parse_fw() wrapper shape
>> - update patch 5 to use that helper shape directly in the client
>> parse_fw() callbacks
>> - drop the post-helper rproc->table_ptr checks from the converted
>> drivers
>> - keep the converted parse_fw() wrappers otherwise close to their
>> existing structure and placement
>> - test xlnx_r5_remoteproc on the latest tree with firmware images
>> both with and without an ELF resource table
>>
>> Changes in v2:
>> - split the mem->is_iomem change out into a separate patch
>> - add a common error message on ioremap_wc() failure
>> - drop logging from the optional resource-table helper
>> - keep driver-local parse_fw() wrappers to preserve per-platform
>> missing-resource-table logging policy
>>
>> Ben Levinsky (5):
>> remoteproc: add common wc-ioremap carveout callbacks
>> remoteproc: switch exact-match drivers to wc-ioremap callbacks
>> remoteproc: mark wc-ioremap carveouts as iomem
>> remoteproc: add helper for optional ELF resource tables
>> remoteproc: switch drivers to optional resource-table helper
>>
>> drivers/remoteproc/imx_dsp_rproc.c | 41 +++-----------
>> drivers/remoteproc/imx_rproc.c | 40 ++------------
>> drivers/remoteproc/rcar_rproc.c | 41 ++------------
>> drivers/remoteproc/remoteproc_internal.h | 38 +++++++++++++
>> drivers/remoteproc/st_remoteproc.c | 31 +----------
>> drivers/remoteproc/stm32_rproc.c | 39 ++-----------
>> drivers/remoteproc/xlnx_r5_remoteproc.c | 70 +++++-------------------
>
>This set looks good to me. I am fine with the checkpatch warning on the macro -
>given the redundancy it avoids, I think it can be tolerated.
>
>Wolfram has already indicated he wanted to test these changes - Arnaud, Daniel
>and Peng, please do the same for your platforms.
Tested-by: Peng Fan <peng.fan@nxp.com> #i.MX8MP-EVK
>
>Thanks,
>Mathieu
>
>> 7 files changed, 73 insertions(+), 227 deletions(-)
>>
>> --
>> 2.34.1
prev parent reply other threads:[~2026-06-06 3:40 UTC|newest]
Thread overview: 9+ 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:16 ` [PATCH v3 2/5] remoteproc: switch exact-match drivers to wc-ioremap callbacks Ben Levinsky
2026-05-29 2:16 ` [PATCH v3 3/5] remoteproc: mark wc-ioremap carveouts as iomem Ben Levinsky
2026-05-29 2:16 ` [PATCH v3 4/5] remoteproc: add helper for optional ELF resource tables Ben Levinsky
2026-05-29 2:16 ` [PATCH v3 5/5] remoteproc: switch drivers to optional resource-table helper Ben Levinsky
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 [this message]
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=aiOXV2k6/4zMh4ST@shlinux89 \
--to=peng.fan@oss.nxp.com \
--cc=Frank.Li@nxp.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andersson@kernel.org \
--cc=arnaud.pouliquen@foss.st.com \
--cc=ben.levinsky@amd.com \
--cc=daniel.baluta@nxp.com \
--cc=festevam@gmail.com \
--cc=geert+renesas@glider.be \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=magnus.damm@gmail.com \
--cc=mathieu.poirier@linaro.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=patrice.chotard@foss.st.com \
--cc=s.hauer@pengutronix.de \
--cc=tanmay.shah@amd.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