kernel/git/stable/linux-stable.git/drivers/remoteproc, branch linux-rolling-stable

remoteproc: qcom: q6v5: Request shutdown if crash is triggered host-side

2026-09-14T11:39:51+00:00

[ Upstream commit 0ea50486978f109e6d4c32267fab01ed654a2160 ] rpmsg client drivers are allowed to invoke rproc_report_crash() on their grandparent when they determine that the otherwise seemingly healthy remoteproc has entered a functionally broken state. In the crash handling path qcom_q6v5_request_stop() is invoked, which is based on the current rproc state whether to request a graceful shutdown. But the current rproc `state` will be RPROC_CRASHED regardless of where the crash handler was initiated from, and empirical data shows that unless the firmware is taking part of the shutdown the system state is often left such that it's not possible to start the subsystem again. Use the `running` state in the q6v5 driver to make the decision instead, as this does represent the actual state of the firmware. This makes it possible to reliably trigger a restart from client drivers. Fixes: 3cc889eb83f5 ("remoteproc: qcom: q6v5: Avoid setting smem bit in case of crash shutdown") Signed-off-by: Bjorn Andersson Reviewed-by: Konrad Dybcio Reviewed-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260723-q6v5-host-side-crash-v1-1-23bd53db90a7@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

remoteproc: qcom: pas: Add late attach support for subsystems

2026-09-14T11:39:51+00:00

[ Upstream commit 16472c99f4699cb28f2f5f946400ead02f58a15e ] Subsystems can be brought out of reset by entities such as bootloaders. As the irq enablement could be later than subsystem bring up, the state of subsystem should be checked by reading SMP2P bits. A new qcom_pas_attach() function is introduced. if crash state is detected for the subsystem, rproc_report_crash() is called. If the ready state is detected meanwhile stop state is not detected, it will be marked as "attached", otherwise it could be the early boot feature is not supported by other entities or it has already been stopped. In above cases, the state will be marked as RPROC_OFFLINE so that the PAS driver can load the firmware and start the remoteproc. Co-developed-by: Gokul Krishna Krishnakumar Signed-off-by: Gokul Krishna Krishnakumar Tested-by: Shawn Guo Signed-off-by: Jingyi Wang Tested-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260623-knp-soccp-v7-5-1ec7bb5c9fec@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 0ea50486978f ("remoteproc: qcom: q6v5: Request shutdown if crash is triggered host-side") Signed-off-by: Sasha Levin

remoteproc: Prevent crash handling to race with rproc_del()

2026-09-14T11:39:51+00:00

[ Upstream commit 74ee3b2f5767447c57959994341e5b95f1079977 ] There's no synchronization between rproc_crash_handler_work() and rproc_del(), as such it's possible for a driver to be removed while crash-handler work is scheduled, or even executing - resulting in use-after-free issues. To avoid this the scheduled work need to be cancelled and synchronized against before the removal proceeds. In order to ensure that this doesn't race with the reporting, and thereby scheduling new work, a "deleting" flag is introduced. This is similar to the RPROC_DELETE state that was introduced to ensure that "start" didn't race with rproc_del(), but the existing mechanism can not be used as it's valid to call rproc_report_crash() in atomic context - and the "state" is protected by a mutex. In the event that work is cancelled the pm_stay_awake() is left unbalanced and need to be unrolled. The blocking and cancelling of crash-handler work prior to the actual rproc_shutdown() call does have the explicit side-effect that crashes resulting from the shutdown process will not enter the crash-handling path, and as such will not generate devcoredumps etc. Due to the existing mutual exclusion between these code paths there's no concrete reduction in functionality, but further work would be needed to handle this case. Assisted-by: OpenCode:GPT-5.5 Fixes: 8afd519c3470 ("remoteproc: add rproc_report_crash function to notify rproc crashes") Signed-off-by: Bjorn Andersson Reviewed-by: Pradnya Dahiwale Link: https://lore.kernel.org/r/20260723-rproc-rmmod-not-crashing-v1-2-546dfd5de0e6@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

remoteproc: core: Attach rproc asynchronously in rproc_add() path via schedule_work()

2026-09-14T11:39:51+00:00

[ Upstream commit 026a3fada43261e403c6c4d9bda9501547e3f108 ] Unlike the remoteproc firmware load path where rproc_add() call rproc_auto_boot_callback() asynchronously and ignores the return value of rproc_boot(), the attach path calls rproc_boot() synchronously and propagates its return value back to rproc_add(). This means a failure during rproc_attach() causes rproc_add() to fail and triggers resource release, removing the remoteproc from sysfs and making it unavailable for recovery or further boot attempts. Align the remoteproc attach path with the firmware load path by introducing attach_work and scheduling rproc_boot() asynchronously via schedule_work(). This keeps the remoteproc registered and available in sysfs even if the initial attach attempt fails, and avoids blocking rproc_add() on the attach result. Signed-off-by: Jingyi Wang Link: https://lore.kernel.org/r/20260623-rproc-attach-issue-v3-1-8e24310707ce@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: 74ee3b2f5767 ("remoteproc: Prevent crash handling to race with rproc_del()") Signed-off-by: Sasha Levin

remoteproc: Allow shutdown of crashed processors

2026-09-14T11:39:50+00:00

[ Upstream commit 2482ca875ef5993df8daee563033d70e2523a25f ] rproc_shutdown() rejects a remoteproc in RPROC_CRASHED state, and rproc_del() ignores that error. The result of these two decisions is that a user cannot stop a remoteproc that with recovery disabled that has entered a crash state, and removal of an associated remoteproc driver will release resources without first stopping the remoteproc. Allow rproc_shutdown() to stop crashed processors. Propagate the crash state to subdevice teardown, to allow subdevices to dismantle things appropriately. Assisted-by: OpenCode:GPT-5.5 Fixes: 5e6a0e05270e ("remoteproc: core: Move state checking to remoteproc_core") Signed-off-by: Bjorn Andersson Reviewed-by: Mukesh Ojha Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260723-rproc-rmmod-not-crashing-v1-1-546dfd5de0e6@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

remoteproc: qcom: Fix glink->node reference leak in qcom_add_glink_subdev

2026-09-14T11:39:32+00:00

[ Upstream commit 44f4911ab8e6f4d69afad5f2571bbd2da421c918 ] In qcom_add_glink_subdev(), the device node reference acquired via of_get_child_by_name() is stored in glink->node. If the subsequent kstrdup_const() allocation for glink->ssr_name fails, the function returns early without calling of_node_put() on glink->node, leaking the reference count. Fix this by adding of_node_put(glink->node) on the error path before returning. Fixes: cd9fc8f1b35b ("remoteproc: qcom: Pass ssr_name to glink subdevice") Signed-off-by: Uday Khare Link: https://lore.kernel.org/r/20260618132054.11010-1-udaykhare77@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

remoteproc: qcom_q6v5_mss: Fix MDM9607 subsystem control instance ID

2026-09-14T11:39:32+00:00

[ Upstream commit 846baa5ab461e24d31f942dcdff1932e8516dd00 ] On MDM9607, the modem firmware exposes the QMI subsystem control service with instance ID 0x22 (34), as visible e.g. with qrtr-lookup: $ qrtr-lookup Service Version Instance Node Port 43 2 34 3 1 Subsystem control service Currently, qcom_q6v5_mss uses ssctl_id 0x12 for all platforms. The QMI service never shows up with this ID, leading to the following error when trying to shutdown the modem: qcom-q6v5-mss 4080000.remoteproc: timeout waiting for ssctl service Set the correct ssctl_id to allow clean shutdown of the modem firmware with the subsystem control service. ssctl_id 0x22 is also used by other modem-only Qualcomm platforms in qcom_q6v5_pas, such as SDX55. Fixes: 4fe236a1d024 ("remoteproc: qcom_q6v5_mss: Add MDM9607") Signed-off-by: Stephan Gerhold Reviewed-by: Mukesh Ojha Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260706-qcom-q6v5-mss-mdm9607-ssctl-id-v1-2-f59e728af621@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

remoteproc: qcom_q6v5_mss: Make ssctl_id configurable per platform

2026-09-14T11:39:32+00:00

[ Upstream commit 6aa64a4c89faec9daff36828df38f8f69498a870 ] Currently, qcom_q6v5_mss hardcodes 0x12 as the instance ID for the subsystem control (ssctl) QMI service. However, some platforms (e.g. MDM9607) provide the service with a different instance ID (0x22). Make it possible to override the ssctl_id per platform by adding it to the platform-specific rproc_hexagon_res struct. The same pattern also exists already inside qcom_q6v5_pas. Signed-off-by: Stephan Gerhold Reviewed-by: Dmitry Baryshkov Reviewed-by: Mukesh Ojha Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260706-qcom-q6v5-mss-mdm9607-ssctl-id-v1-1-f59e728af621@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: 846baa5ab461 ("remoteproc: qcom_q6v5_mss: Fix MDM9607 subsystem control instance ID") Signed-off-by: Sasha Levin

remoteproc: qcom_wcnss: Fix handling the lack of PD regulators in v3

2026-09-14T11:39:22+00:00

[ Upstream commit 3dbc90b9c22ea96e37bf55f6011e63b5123ec668 ] The changes introduced to handle single power domain platforms have swapped the info pointer increment from num_pd_vregs to num_pds, which would shift the info pointer past the end of the array for pronto-v3, which does not list power domain regulators in vregs. This showed up as a difference between GCC- and LLVM-compiled kernels on SDM632 devices, where only with LLVM one would get the "regulator request with no identifier" error, because the out-of-bounds memory ended up being zeroed. Fix by skipping the increment when there are more power domains than regulators. Signed-off-by: Val Packett Fixes: 65991ea8a6d1 ("remoteproc: qcom_wcnss: Handle platforms with only single power domain") Reviewed-by: Konrad Dybcio Fixes: 65991ea8a6d1 ("remoteproc: qcom_wcnss: Handle platforms with only single power domain") Link: https://lore.kernel.org/r/20260201210230.911220-1-val@packett.cool Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

remoteproc: qcom_q6v5_adsp: Fix reference leak for device node

2026-09-14T11:39:22+00:00

[ Upstream commit 8c952807c2cebd5e9e9b37146c9383229794c129 ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In adsp_map_carveout, it does not release the reference. Fixes: f22eedff28af ("remoteproc: qcom: Add support for memory sandbox") Signed-off-by: Felix Gu Link: https://lore.kernel.org/r/tencent_EDC2253D3B1C22217E1259E07765D269100A@qq.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin