kernel/linux.git/drivers/remoteproc, branch v7.0.11

remoteproc: imx_rproc: Check return value of regmap_attach_dev() in imx_rproc_mmio_detect_mode()

2026-05-23T11:09:05+00:00

[ Upstream commit a48c6676912fb808d2af1b8344d8656815a3e108 ] Add error checking for regmap_attach_dev() call in imx_rproc_mmio_detect_mode() function to ensure proper error propagation. Return the value of regmap_attach_dev() if it fails to prevent proceeding with an incomplete regmap setup. Suggested-by: Peng Fan Signed-off-by: Chen Ni Fixes: e14168bf3493 ("remoteproc: imx_rproc: Simplify IMX_RPROC_MMIO switch case") Link: https://lore.kernel.org/r/20260209051407.1467660-1-nichen@iscas.ac.cn Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin

remoteproc: xlnx: Fix sram property parsing

2026-05-23T11:09:05+00:00

[ Upstream commit d116bccf6f1c199b27c9ebdf07cc3cfe868f919c ] As per sram bindings, "sram" property can be list of phandles. When more than one sram phandles are listed, driver can't parse second phandle's address correctly. Because, phandle index is passed to the API instead of offset of address from reg property which is always 0 as per sram.yaml bindings. Fix it by passing 0 to the API instead of sram phandle index. Fixes: 77fcdf51b8ca ("remoteproc: xlnx: Add sram support") Signed-off-by: Tim Michals Signed-off-by: Tanmay Shah Link: https://lore.kernel.org/r/20260204202730.3729984-1-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin

remoteproc: k3: Fix NULL vs IS_ERR() bug in k3_reserved_mem_init()

2026-05-14T13:31:16+00:00

commit 5b1f4b5c72cc40e676293b8609cacef7e1545beb upstream. The devm_ioremap_resource_wc() function never returns NULL, it returns error pointers. Update the error checking to match. Fixes: 67a7bc7f0358 ("remoteproc: Use of_reserved_mem_region_* functions for "memory-region"") Signed-off-by: Chen Ni Reviewed-by: Peng Fan Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260227092110.4044313-1-nichen@iscas.ac.cn Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman

remoteproc: imx_rproc: Fix NULL vs IS_ERR() bug in imx_rproc_addr_init()

2026-05-14T13:31:16+00:00

commit 665eebebb029690a5b2f92e481020877cc6c8d36 upstream. The devm_ioremap_resource_wc() function never returns NULL, it returns error pointers. Update the error checking to match. Fixes: 67a7bc7f0358 ("remoteproc: Use of_reserved_mem_region_* functions for "memory-region"") Signed-off-by: Chen Ni Reviewed-by: Peng Fan Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260227091546.4044246-1-nichen@iscas.ac.cn Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman

remoteproc: xlnx: Only access buffer information if IPI is buffered

2026-05-07T04:13:52+00:00

commit 38dd6ccfdfbbe865569a52fe1ba9fa1478f672e6 upstream. In the receive callback check if message is NULL to prevent possibility of crash by NULL pointer dereferencing. Signed-off-by: Ben Levinsky Signed-off-by: Tanmay Shah Fixes: 5dfb28c257b7 ("remoteproc: xilinx: Add mailbox channels for rpmsg") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260303235127.2317955-3-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman

remoteproc: imx_rproc: Fix unreachable platform prepare_ops

2026-03-05T17:18:23+00:00

Smatch reports unreachable code in imx_rproc_prepare(), where an early return inside the reserved-memory parsing loop prevents platform prepare_ops from being executed. When of_reserved_mem_region_to_resource() fails, imx_rproc_prepare() returns immediately, so the platform-specific prepare callback is never called. As a result, prepare_ops such as imx_rproc_sm_lmm_prepare() on i.MX95 have no chance to run. This is problematic when Linux controls the M7 Logical Machine and is responsible for preparing resources such as TCM. Without running the platform prepare callback, loading the M7 ELF into TCM may fail if the bootloader did not power up and initialize TCM. Fix this by breaking out of the reserved-memory loop instead of returning, allowing the platform prepare_ops to be executed as intended. Fixes: edd2a9956055 ("remoteproc: imx_rproc: Introduce prepare ops for imx_rproc_dcfg") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-remoteproc/aYYXAa2Fj36XG4yQ@p14s/T/#t Signed-off-by: Peng Fan Reviewed-by: Daniel Baluta Link: https://lore.kernel.org/r/20260208-imx-rproc-fix-v1-1-ad74555eb9a4@nxp.com Signed-off-by: Mathieu Poirier

remoteproc: mediatek: Unprepare SCP clock during system suspend

2026-03-05T17:14:36+00:00

Prior to commit d935187cfb27 ("remoteproc: mediatek: Break lock dependency to prepare_lock"), `scp->clk` was prepared and enabled only when it needs to communicate with the SCP. The commit d935187cfb27 moved the prepare operation to remoteproc's prepare(), keeping the clock prepared as long as the SCP is running. The power consumption due to the prolonged clock preparation can be negligible when the system is running, as SCP is designed to be a very power efficient processor. However, the clock remains prepared even when the system enters system suspend. This prevents the underlying clock controller (and potentially the parent PLLs) from shutting down, which increases power consumption and may block the system from entering deep sleep states. Add suspend and resume callbacks. Unprepare the clock in suspend() if it was active and re-prepare it in resume() to ensure the clock is properly disabled during system suspend, while maintaining the "always prepared" semantics while the system is active. The driver doesn't implement .attach() callback, hence it only checks for RPROC_RUNNING. Fixes: d935187cfb27 ("remoteproc: mediatek: Break lock dependency to prepare_lock") Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20260206033034.3031781-1-tzungbi@kernel.org Signed-off-by: Mathieu Poirier

remoteproc: sysmon: Correct subsys_name_len type in QMI request

2026-03-04T19:12:06+00:00

The QMI message encoder has up until recently read a single byte (as elem_size == 1), but with the introduction of big endian support it's become apparent that this field is expected to be a full u32 - regardless of the size of the length in the encoded message (which is what elem_size specifies). The result is that the encoder now reads past the length byte and rejects the unreasonably large length formed when including the following 3 bytes from the subsys_name array. Fix this by changing to the expected type. Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon") Signed-off-by: Bjorn Andersson Reviewed-by: Chris Lew Link: https://lore.kernel.org/r/20260220-qmi-encode-invalid-length-v2-1-5674be35ab29@oss.qualcomm.com Signed-off-by: Bjorn Andersson

remoteproc: qcom_wcnss: Fix reserved region mapping failure

2026-02-23T19:57:37+00:00

Commit c70b9d5fdcd7 ("remoteproc: qcom: Use of_reserved_mem_region_* functions for "memory-region"") switched from devm_ioremap_wc() to devm_ioremap_resource_wc(). The difference is devm_ioremap_resource_wc() also requests the resource which fails. Testing of both fixed and dynamic reserved regions indicates that requesting the resource should work, so I'm not sure why it doesn't work in this case. Fix the issue by reverting back to devm_ioremap_wc(). Reported-by: Marek Szyprowski Reported-by: André Apitzsch Fixes: c70b9d5fdcd7 ("remoteproc: qcom: Use of_reserved_mem_region_* functions for "memory-region"") Signed-off-by: Rob Herring (Arm) Tested-by: Marek Szyprowski Tested-by: André Apitzsch # on BQ Aquaris M5 Link: https://lore.kernel.org/r/20260128220243.3018526-1-robh@kernel.org Signed-off-by: Bjorn Andersson

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\