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

remoteproc: mediatek: Unprepare SCP clock during system suspend

2026-03-25T10:08:25+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-25T10:08:25+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:52+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:21:21+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:21:21+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: qcom_q6v5_wcss: fix parsing of qcom,halt-regs

2025-12-18T12:55:13+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: qcom: q6v5: Avoid handling handover twice

2025-11-13T20:34:28+00:00

[ Upstream commit 54898664e1eb6b5b3e6cdd9343c6eb15da776153 ] A remoteproc could theoretically signal handover twice. This is unexpected and would break the reference counting for the handover resources (power domains, clocks, regulators, etc), so add a check to prevent that from happening. Reviewed-by: Dmitry Baryshkov Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20250820-rproc-qcom-q6v5-fixes-v2-2-910b1a3aff71@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

remoteproc: wkup_m3: Use devm_pm_runtime_enable() helper

2025-11-13T20:34:15+00:00

[ Upstream commit 461edcf73eec57bc0006fbb5209f5012c514c58b ] Use device life-cycle managed runtime enable function to simplify probe and exit paths. Signed-off-by: Andrew Davis Link: https://lore.kernel.org/r/20250814153940.670564-1-afd@ti.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin

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

2025-10-15T10:00:24+00:00

commit d41e075b077142bb9ae5df40b9ddf9fd7821a811 upstream. 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 Signed-off-by: Greg Kroah-Hartman

remoteproc: qcom: q6v5: Avoid disabling handover IRQ twice

2025-10-15T10:00:15+00:00

[ Upstream commit 110be46f5afe27b66caa2d12473a84cd397b1925 ] enable_irq() and disable_irq() are reference counted, so we must make sure that each enable_irq() is always paired with a single disable_irq(). If we call disable_irq() twice followed by just a single enable_irq(), the IRQ will remain disabled forever. For the error handling path in qcom_q6v5_wait_for_start(), disable_irq() will end up being called twice, because disable_irq() also happens in qcom_q6v5_unprepare() when rolling back the call to qcom_q6v5_prepare(). Fix this by dropping disable_irq() in qcom_q6v5_wait_for_start(). Since qcom_q6v5_prepare() is the function that calls enable_irq(), it makes more sense to have the rollback handled always by qcom_q6v5_unprepare(). Fixes: 3b415c8fb263 ("remoteproc: q6v5: Extract common resource handling") Reviewed-by: Dmitry Baryshkov Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20250820-rproc-qcom-q6v5-fixes-v2-1-910b1a3aff71@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin