[PATCH v3 0/5] remoteproc: cleanup shared carveout and resource-table helpers

Ben Levinsky posted 5 patches 1 week, 3 days ago
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 +++++-------------------
7 files changed, 73 insertions(+), 227 deletions(-)
[PATCH v3 0/5] remoteproc: cleanup shared carveout and resource-table helpers
Posted by Ben Levinsky 1 week, 3 days ago
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 +++++-------------------
 7 files changed, 73 insertions(+), 227 deletions(-)

-- 
2.34.1
Re: [PATCH v3 0/5] remoteproc: cleanup shared carveout and resource-table helpers
Posted by Mathieu Poirier 6 days, 21 hours ago
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.

Thanks,
Mathieu

>  7 files changed, 73 insertions(+), 227 deletions(-)
> 
> -- 
> 2.34.1
Re: [PATCH v3 0/5] remoteproc: cleanup shared carveout and resource-table helpers
Posted by Wolfram Sang 21 hours ago
> Wolfram has already indicated he wanted to test these changes - Arnaud, Daniel
> and Peng, please do the same for your platforms.

Testing is more involved than I expected. Didn't work out this week.
I'll keep trying for next week. But it may end up the week after that.
Re: [PATCH v3 0/5] remoteproc: cleanup shared carveout and resource-table helpers
Posted by Peng Fan 2 days, 8 hours ago
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
Re: [PATCH v3 0/5] remoteproc: cleanup shared carveout and resource-table helpers
Posted by Wolfram Sang 1 week, 3 days ago
Hi Ben,

> 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.

Thank you for this work, much appreciated! I want to test the changes to
the Renesas R-Car driver but can only do so early next week due to
travels. I hope I have time for review comments earlier, though.

Thanks and happy hacking,

   Wolfram