kernel/linux.git/drivers/remoteproc, branch v6.18.21

remoteproc: mediatek: Unprepare SCP clock during system suspend

2026-03-19T15:08:12+00:00

[ Upstream commit 35c3f72a2d55dbf52f28f4ecae51c76be1acf545 ] 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 Signed-off-by: Sasha Levin

remoteproc: sysmon: Correct subsys_name_len type in QMI request

2026-03-19T15:08:11+00:00

[ Upstream commit da994db94e60f9a9411108ddf4d1836147ad4c9c ] 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 Signed-off-by: Sasha Levin

remoteproc: imx_rproc: Fix invalid loaded resource table detection

2026-03-04T12:21:22+00:00

[ Upstream commit 26aa5295010ffaebcf8f1991c53fa7cf2ee1b20d ] imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded resource table even when the current firmware does not provide one. When the device tree contains a "rsc-table" entry, priv->rsc_table is non-NULL and denotes where a resource table would be located if one is present in memory. However, when the current firmware has no resource table, rproc->table_ptr is NULL. The function still returns priv->rsc_table, and the remoteproc core interprets this as a valid loaded resource table. Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when there is no resource table for the current firmware (i.e. when rproc->table_ptr is NULL). This aligns the function's semantics with the remoteproc core: a loaded resource table is only reported when a valid table_ptr exists. With this change, starting firmware without a resource table no longer triggers a crash. Fixes: e954a1bd1610 ("remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table") Cc: stable@vger.kernel.org Signed-off-by: Peng Fan Acked-by: Daniel Baluta Link: https://lore.kernel.org/r/20260129-imx-rproc-fix-v3-1-fc4e41e6e750@nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin

remoteproc: mediatek: Break lock dependency to `prepare_lock`

2026-03-04T12:20:30+00:00

[ Upstream commit d935187cfb27fc4168f78f3959aef4eafaae76bb ] A potential circular locking dependency (ABBA deadlock) exists between `ec_dev->lock` and the clock framework's `prepare_lock`. The first order (A -> B) occurs when scp_ipi_send() is called while `ec_dev->lock` is held (e.g., within cros_ec_cmd_xfer()): 1. cros_ec_cmd_xfer() acquires `ec_dev->lock` and calls scp_ipi_send(). 2. scp_ipi_send() calls clk_prepare_enable(), which acquires `prepare_lock`. See #0 in the following example calling trace. (Lock Order: `ec_dev->lock` -> `prepare_lock`) The reverse order (B -> A) is more complex and has been observed (learned) by lockdep. It involves the clock prepare operation triggering power domain changes, which then propagates through sysfs and power supply uevents, eventually calling back into the ChromeOS EC driver and attempting to acquire `ec_dev->lock`: 1. Something calls clk_prepare(), which acquires `prepare_lock`. It then triggers genpd operations like genpd_runtime_resume(), which takes `&genpd->mlock`. 2. Power domain changes can trigger regulator changes; regulator changes can then trigger device link changes; device link changes can then trigger sysfs changes. Eventually, power_supply_uevent() is called. 3. This leads to calls like cros_usbpd_charger_get_prop(), which calls cros_ec_cmd_xfer_status(), which then attempts to acquire `ec_dev->lock`. See #1 ~ #6 in the following example calling trace. (Lock Order: `prepare_lock` -> `&genpd->mlock` -> ... -> `&ec_dev->lock`) Move the clk_prepare()/clk_unprepare() operations for `scp->clk` to the remoteproc prepare()/unprepare() callbacks. This ensures `prepare_lock` is only acquired in prepare()/unprepare() callbacks. Since `ec_dev->lock` is not involved in the callbacks, the dependency loop is broken. This means the clock is always "prepared" when the SCP is running. The prolonged "prepared time" for the clock should be acceptable as SCP is designed to be a very power efficient processor. The power consumption impact can be negligible. A simplified calling trace reported by lockdep: > -> #6 (&ec_dev->lock) > cros_ec_cmd_xfer > cros_ec_cmd_xfer_status > cros_usbpd_charger_get_port_status > cros_usbpd_charger_get_prop > power_supply_get_property > power_supply_show_property > power_supply_uevent > dev_uevent > uevent_show > dev_attr_show > sysfs_kf_seq_show > kernfs_seq_show > -> #5 (kn->active#2) > kernfs_drain > __kernfs_remove > kernfs_remove_by_name_ns > sysfs_remove_file_ns > device_del > __device_link_del > device_links_driver_bound > -> #4 (device_links_lock) > device_link_remove > _regulator_put > regulator_put > -> #3 (regulator_list_mutex) > regulator_lock_dependent > regulator_disable > scpsys_power_off > _genpd_power_off > genpd_power_off > -> #2 (&genpd->mlock/1) > genpd_add_subdomain > pm_genpd_add_subdomain > scpsys_add_subdomain > scpsys_probe > -> #1 (&genpd->mlock) > genpd_runtime_resume > __rpm_callback > rpm_callback > rpm_resume > __pm_runtime_resume > clk_core_prepare > clk_prepare > -> #0 (prepare_lock) > clk_prepare > scp_ipi_send > scp_send_ipi > mtk_rpmsg_send > rpmsg_send > cros_ec_pkt_xfer_rpmsg Signed-off-by: Tzung-Bi Shih Reviewed-by: Chen-Yu Tsai Tested-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20260112110755.2435899-1-tzungbi@kernel.org Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin

remoteproc: imx_dsp_rproc: Skip RP_MBOX_SUSPEND_SYSTEM when mailbox TX channel is uninitialized

2026-03-04T12:20:29+00:00

[ Upstream commit d62e0e92e589c53c4320ed5914af5fe103f5ce7e ] Firmwares that do not use mailbox communication (e.g., the hello_world sample) leave priv->tx_ch as NULL. The current suspend logic unconditionally sends RP_MBOX_SUSPEND_SYSTEM, which is invalid without an initialized TX channel. Detect the no_mailboxes case early and skip sending the suspend message. Instead, proceed directly to the runtime PM suspend path, which is the correct behavior for firmwares that cannot respond to mailbox requests. Signed-off-by: Iuliana Prodan Link: https://lore.kernel.org/r/20251204122825.756106-1-iuliana.prodan@oss.nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin

remoteproc: imx_dsp_rproc: Only reset carveout memory at RPROC_OFFLINE state

2026-02-26T22:59:28+00:00

[ Upstream commit b490ddf27be28e64a39c08ae643d7b22561beaf6 ] Do not reset memory at suspend and resume stage, because some memory is used to save the software state for resume, if it is cleared, the resume operation can fail. Fixes: c4c432dfb00f ("remoteproc: imx_dsp_rproc: Add support of recovery and coredump process") Signed-off-by: Shengjiu Wang Reviewed-by: Daniel Baluta Reviewed-by: Iuliana Prodan Link: https://lore.kernel.org/r/20251218071750.2692132-1-shengjiu.wang@nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin

remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs

2025-12-18T13:03:28+00:00

[ Upstream commit 7e81fa8d809ed1e67ae9ecd52d20a20c2c65d877 ] The "qcom,halt-regs" consists of a phandle reference followed by the three offsets within syscon for halt registers. Thus, we need to request 4 integers from of_property_read_variable_u32_array(), with the halt_reg ofsets at indexes 1, 2, and 3. Offset 0 is the phandle. With MAX_HALT_REG at 3, of_property_read_variable_u32_array() returns -EOVERFLOW, causing .probe() to fail. Increase MAX_HALT_REG to 4, and update the indexes accordingly. Fixes: 0af65b9b915e ("remoteproc: qcom: wcss: Add non pas wcss Q6 support for QCS404") Signed-off-by: Alexandru Gagniuc Link: https://lore.kernel.org/r/20251129013207.3981517-1-mr.nuke.me@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path

2025-12-18T13:02:28+00:00

[ Upstream commit 80405a34e1f8975cdb2d7d8679bca7f768861035 ] Proper cleanup should be done when rproc_add() fails by invoking both pm_runtime_disable() and pm_runtime_put_noidle() to avoid leaving the device in an inconsistent power state. Fix it by adding pm_runtime_put_noidle() and pm_runtime_disable() in the error path. Also Update the remove() callback to use pm_runtime_put_noidle() instead of pm_runtime_put(), to clearly indicate that only need to restore the usage count. Fixes: a876a3aacc43 ("remoteproc: imx_rproc: detect and attach to pre-booted remote cores") Cc: Ulf Hansson Cc: Hiago De Franco Suggested-by: Ulf Hansson Signed-off-by: Peng Fan Reviewed-by: Ulf Hansson Link: https://lore.kernel.org/r/20250926-imx_rproc_v3-v3-1-4c0ec279cc5f@nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin

Merge tag 'rproc-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux

2025-10-04T22:45:17+00:00

Pull remoteproc updates from Bjorn Andersson: - Enable coredump support for the i.MX HiFi core remoteproc, and clean up the i.MX remoteproc driver. - Introduce remoteprocs on the Qualcomm Milos platform. Gracefully shut own the ADSP remoteproc when bootloader has loaded the "Lite" firmware on X Elite. Improve the resource handover procedure to avoid possibly duplicate handling. - Transition the TI DA8xx, TI Keystone, and TI Wakeup M3 remoteproc drivers to handle resources using devres. * tag 'rproc-v6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: (29 commits) remoteproc: pru: Fix potential NULL pointer dereference in pru_rproc_set_ctable() remoteproc: qcom: pas: Drop redundant assignment to ret remoteproc: qcom: pas: Shutdown lite ADSP DTB on X1E remoteproc: qcom: q6v5: Avoid handling handover twice remoteproc: qcom: q6v5: Avoid disabling handover IRQ twice remoteproc: qcom: pas: Add Milos remoteproc support dt-bindings: remoteproc: qcom,milos-pas: Document remoteprocs remoteproc: qcom_q6v5_mss: support loading MBN file on msm8974 remoteproc: imx_rproc: Clean up after ops introduction remoteproc: imx_rproc: Simplify IMX_RPROC_SMC switch case remoteproc: imx_rproc: Simplify IMX_RPROC_SCU_API switch case remoteproc: imx_rproc: Simplify IMX_RPROC_MMIO switch case remoteproc: imx_rproc: Move imx_rproc_dcfg closer to imx_rproc_of_match remoteproc: imx_rproc: Introduce start/stop/detect_mode ops for imx_rproc_dcfg remoteproc: k3: Correctly release some resources allocated in k3_rproc_request_mbox() remoteproc: wkup_m3: Use devm_rproc_add() helper remoteproc: wkup_m3: Use devm_rproc_alloc() helper remoteproc: wkup_m3: Use devm action to call PM runtime put sync remoteproc: wkup_m3: Use devm_pm_runtime_enable() helper remoteproc: keystone: Use devm_rproc_add() helper ...

remoteproc: pru: Fix potential NULL pointer dereference in pru_rproc_set_ctable()

2025-09-23T17:49:58+00:00

pru_rproc_set_ctable() accessed rproc->priv before the IS_ERR_OR_NULL check, which could lead to a null pointer dereference. Move the pru assignment, ensuring we never dereference a NULL rproc pointer. Fixes: 102853400321 ("remoteproc: pru: Add pru_rproc_set_ctable() function") Cc: stable@vger.kernel.org Signed-off-by: Zhen Ni Link: https://lore.kernel.org/r/20250923112109.1165126-1-zhen.ni@easystack.cn Signed-off-by: Mathieu Poirier