linux.git/drivers/remoteproc, branch master

remoteproc: qcom: pas: Add Nord ADSP and CDSP support

2026-08-04T15:47:20+00:00

Add support for ADSP (HPASS DSP) and 4 CDSPs found on Nord SoC. The ADSP
is pre-booted by XBL before Linux starts, so set early_boot flag for
attach path rather than a cold boot sequence.

Reviewed-by: Konrad Dybcio 
Signed-off-by: Shawn Guo 
Link: https://lore.kernel.org/r/20260729023508.879752-4-shengchao.guo@oss.qualcomm.com
Signed-off-by: Bjorn Andersson

remoteproc: qcom: pas: Drop unused dtb_mem_region field

2026-07-31T02:44:44+00:00

dtb_mem_region is no longer referenced after the ioremap was moved
to respective places where mapping is required. Remove it from
struct qcom_pas.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Mukesh Ojha 
Link: https://lore.kernel.org/r/20260724182858.1868271-6-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson

remoteproc: qcom: pas: Map/unmap subsystem region before auth_and_reset

2026-07-31T02:44:44+00:00

Qualcomm remoteproc drivers such as qcom_q6v5_mss, which do not use the
Peripheral Authentication Service (PAS), always map the MBA region before
use and unmap it once the usage is complete. This behavior was introduced
to avoid issues seen in the past where speculative accesses from the
application processor to the MBA region after it was assigned to the remote
Q6 led to an XPU violation. The issue was mitigated by unmapping the region
before handing control to the remote Q6.

Currently, most Qualcomm SoCs using the PAS driver run either with a
standalone QHEE or the Gunyah hypervisor. In these environments, the
hypervisor unmaps the Q6 memory from HLOS Stage-2 and remaps it into the
Q6 Stage-2 page table. As a result, speculative accesses from HLOS cannot
reach the region even if it remains mapped in HLOS Stage-1; therefore, XPU
violations cannot occur.

However, when the same SoC runs Linux at EL2, Linux itself must perform the
unmapping to avoid such issues. It is still correct to apply this mapping/
unmapping sequence even for SoCs that run under Gunyah, so this behavior
should not be conditional.

Introduce qcom_pas_ctx_map() in qcom_pas.h to centralise the ioremap_wc
pattern used by both qcom_q6v5_pas and qcom_mdt_pas_load, and use it in
both places.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Mukesh Ojha 
Link: https://lore.kernel.org/r/20260724182858.1868271-5-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson

remoteproc: qcom: pas: Fix the PAS context creation placement

2026-07-31T02:44:44+00:00

DTB PAS context creation should be done only for subsystems that support
a DTB firmware binary; otherwise, memory is wasted. Move the context
creation to the appropriate location.

Reviewed-by: Konrad Dybcio 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Mukesh Ojha 
Link: https://lore.kernel.org/r/20260724182858.1868271-4-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson

remoteproc: qcom: pas: Guard dtb metadata release with dtb_pas_id check

2026-07-31T02:44:44+00:00

All other call sites of qcom_scm_pas_metadata_release() for the DTB
context are guarded by a check on pas->dtb_pas_id, but the call inside
qcom_pas_load() was not. Fix this by moving the call to the guarded
block.

Reviewed-by: Konrad Dybcio 
Fixes: 29814986b82e ("remoteproc: qcom_q6v5_pas: add support for dtb co-firmware loading")
Cc: stable@vger.kernel.org
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Mukesh Ojha 
Link: https://lore.kernel.org/r/20260724182858.1868271-3-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson

remoteproc: qcom: annotate mem_region fields with __iomem

2026-07-31T02:44:44+00:00

The firmware memory regions in qcom_adsp, qcom_pas and qcom_wcnss are
mapped using devm_ioremap_wc() / devm_ioremap_resource_wc(), which
return void __iomem *. However, the mem_region (and dtb_mem_region)
fields in the respective driver structs were declared as plain void *,
causing sparse to flag address space mismatches:

qcom_q6v5_adsp.c:639:26: warning: incorrect type in assignment (different address spaces)
qcom_q6v5_adsp.c:639:26:    expected void *mem_region
qcom_q6v5_adsp.c:639:26:    got void [noderef] __iomem *
qcom_q6v5_pas.c:141:45: warning: incorrect type in argument 2 (different address spaces)
qcom_q6v5_pas.c:141:45:    expected void const volatile [noderef] __iomem *src
qcom_q6v5_pas.c:141:45:    got void *
qcom_q6v5_pas.c:637:25: warning: incorrect type in assignment (different address spaces)
qcom_q6v5_pas.c:637:25:    expected void *mem_region
qcom_q6v5_pas.c:637:25:    got void [noderef] __iomem *
qcom_q6v5_pas.c:654:29: warning: incorrect type in assignment (different address spaces)
qcom_q6v5_pas.c:654:29:    expected void *dtb_mem_region
qcom_q6v5_pas.c:654:29:    got void [noderef] __iomem *
qcom_wcnss.c:540:27: warning: incorrect type in assignment (different address spaces)
qcom_wcnss.c:540:27:    expected void *mem_region
qcom_wcnss.c:540:27:    got void [noderef] __iomem *

Fix this by annotating the struct fields with __iomem to correctly
reflect the address space of the underlying mapping.

These regions are subsequently passed to qcom_mdt_load(),
qcom_mdt_load_no_init() and qcom_mdt_pas_load(), all of which take
void * and use plain memcpy()/memset() internally to write firmware
segments into the region. This is intentional and safe: the mappings
are write-combining (WC), which on arm64 permits bulk CPU stores
without requiring the memcpy_toio()/memset_io() accessors. Changing
the MDT loader API to accept void __iomem * would be a more invasive
change and would affect callers.

Signed-off-by: Mukesh Ojha 
Link: https://lore.kernel.org/r/20260724182858.1868271-2-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson

remoteproc: qcom: pas: Add Eliza CDSP support

2026-07-30T22:35:12+00:00

Add dedicated driver data for the Eliza CDSP remote processor. It looks
almost the same as for Milos, except Eliza needs region assign.
Tie the new driver data to the Eliza specific compatible.

Reviewed-by: Konrad Dybcio 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Abel Vesa 
Link: https://lore.kernel.org/r/20260722-remoteproc-eliza-cdsp-v4-2-04c6eee70cb1@oss.qualcomm.com
Signed-off-by: Bjorn Andersson

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

2026-07-28T01:20:10+00:00

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

remoteproc: Force shutdown during device removal

2026-07-28T01:18:31+00:00

rproc_del() is subjected to the reference counted shutdown path, as such
a remoteproc with more than one reference will be left running as its
resources are released underneath it.

Refactor the shutdown path such that the reference count value is
ignored when called from rproc_del().

Assisted-by: OpenCode:GPT-5.5
Signed-off-by: Bjorn Andersson 
Reviewed-by: Pradnya Dahiwale 
Reviewed-by: Konrad Dybcio 
Link: https://lore.kernel.org/r/20260723-rproc-rmmod-not-crashing-v1-3-546dfd5de0e6@oss.qualcomm.com
Signed-off-by: Bjorn Andersson

remoteproc: Prevent crash handling to race with rproc_del()

2026-07-28T01:18:30+00:00

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