wireguard-linux/drivers/remoteproc, branch stable

remoteproc: qcom_q6v5_pas: Fix error masking in qcom_pas_stop()

2026-08-31T16:45:00Z

In qcom_pas_stop function, return value of qcom_pas_shutdown for pas_id is overwritten by the return value of qcom_pas_shutdown for dtb_pas_id. This causes errors seen on qcom_pas_shutdown failures for pas_id to be masked to the caller. This might lead to issues where the memory regions locked by PAS, as part of qcom_pas_auth_and_reset, are not released for access by linux and rproc_coredump flow will end up accessing the locked memory, leading to an access violation. Fix this by using a separate variable for the dtb_pas_id shutdown call and only overriding the main return value if the pas_id shutdown succeeded but dtb_pas_id shutdown failed. Fixes: 29814986b82e ("remoteproc: qcom_q6v5_pas: add support for dtb co-firmware loading") Signed-off-by: Vignesh Viswanathan Reviewed-by: Konrad Dybcio Reviewed-by: Mukesh Ojha Link: https://lore.kernel.org/r/20260819-rproc_dtb_fix-v1-1-cb6be7f93bc9@oss.qualcomm.com Signed-off-by: Bjorn Andersson

remoteproc: qcom_q6v5_adsp: Fix iommu_unmap() usage

2026-08-31T16:33:12Z

During adsp_map_carveout, the IOVA is computed by combining the physical address and the SID: iova = adsp->mem_phys | (sid << 32); However, adsp_unmap_carveout() uses the physical address and not the IOVA in iommu_unmap(), causing the unmap to fail or leak mappings because the address doesn't match the original IOVA. Cache the constructed IOVA within the qcom_adsp device struct during mapping and use it during unmapping. Fixes: f22eedff28af ("remoteproc: qcom: Add support for memory sandbox") Signed-off-by: Mostafa Saleh Link: https://lore.kernel.org/r/20260827203055.640116-1-smostafa@google.com Signed-off-by: Bjorn Andersson

remoteproc: qcom_q6v5_mss: Don't require PAS for memory protection

2026-08-31T16:28:45Z

Commit f3b1357673dd ("remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs") changed the probe-time gate for need_mem_protection platforms from qcom_scm_is_available() to qcom_pas_is_available(). Memory protection in this driver is implemented with qcom_scm_assign_mem(), which is a TZ service distinct from PAS. The only PAS call in the driver is qcom_pas_mem_setup(), and it is already guarded by need_pas_mem_setup. No descriptor sets both flags: sc7180, sc7280, sdm660, sdm845, msm8996 and msm8998 set need_mem_protection only, while msm8937, msm8940 and msm8953 set need_pas_mem_setup only. On TrustZone firmware that does not implement PAS - for example SC7180 Chromebooks, where call-availability queries report every QCOM_SCM_SVC_PIL command as unavailable - the modem consequently never probes: platform 4080000.remoteproc: deferred probe pending: (reason unknown) On those machines the modem is also what loads the WLAN firmware, so ath10k never receives QMI and wifi does not come up either. Gate memory protection on SCM availability as it was before, and require PAS only where a PAS call is actually issued. Keeping the SCM check matters: qcom_scm_assign_mem() passes __scm->mempool to qcom_tzmem_alloc() without testing __scm, so dropping the gate entirely would allow a NULL dereference when qcom_scm has not yet probed. Fixes: f3b1357673dd ("remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs") Link: https://lore.kernel.org/r/20260808034716.58888-1-phollinsky@holtechnik.com Signed-off-by: Paul Hollinsky Reviewed-by: Abel Vesa Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20260821081540.89137-1-phollinsky@holtechnik.com Signed-off-by: Bjorn Andersson

remoteproc: qcom: q6v5_pas: Don't enable handover IRQ on attach

2026-08-31T16:01:09Z

qcom_pas_attach() unmasks the handover IRQ and marks handover_issued even though this driver instance never runs qcom_q6v5_prepare() for the boot it is attaching to. This was believed necessary to flush a stale interrupt latched at the interrupt controller while masked, but the handover IRQ is a Qualcomm SMP2P soft IRQ, not a real edge-latched hardware interrupt. The Linux SMP2P driver updates its cached value unconditionally on every notification and only delivers the nested IRQ for bits currently enabled in its own software bitmap, so a transition that happens while masked is simply dropped, never replayed on a later unmask. Since there is nothing to flush, and this driver instance never takes the proxy power-domain/clock/regulator votes that the handover callback would tear down, there is no need to unmask the IRQ in attach() at all. Drop the enable_irq()/disable_irq() pair; setting handover_issued = true is sufficient to keep the flag consistent for the eventual qcom_q6v5_unprepare()/qcom_q6v5_prepare() cycle. It fixes the following unbalanced runtime PM usage and IRQ enable warnings seen on Nord ADSP (probed as attached), after commit bb7c5d6f5b41 ("remoteproc: qcom: q6v5: Make handover IRQ one-shot") comes in place. root@iq10-rrd:~# cat /sys/class/remoteproc/remoteproc0/state attached root@iq10-rrd:~# echo stop > /sys/class/remoteproc/remoteproc0/state [ 40.004874] genpd genpd:0:4c00000.remoteproc: Runtime PM usage count underflow! [ 40.012409] genpd genpd:1:4c00000.remoteproc: Runtime PM usage count underflow! [ 40.050074] remoteproc remoteproc0: stopped remote processor adsp root@iq10-rrd:~# echo start > /sys/class/remoteproc/remoteproc0/state [ 44.350298] remoteproc remoteproc0: powering up adsp [ 44.375769] remoteproc remoteproc0: Booting fw image qcom/nord/adsp.mbn, size 8241816 [ 44.389850] PDM: no support for the platform, userspace daemon might be required. [ 44.397864] ------------[ cut here ]------------ [ 44.402633] Unbalanced enable for IRQ 363 [ 44.406779] WARNING: kernel/irq/manage.c:775 at __enable_irq+0x4c/0x7c, CPU#9: sh/791 ... Suggested-by: Stephan Gerhold Signed-off-by: Shawn Guo Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20260801011731.1084591-1-shengchao.guo@oss.qualcomm.com Signed-off-by: Bjorn Andersson

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

2026-08-04T15:47:20Z

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:44Z

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:44Z

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:44Z

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:44Z

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:44Z

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