Add a dedicated binding for the Qualcomm Nord SoC PAS devices: ADSP
and CDSPs. Nord ADSP uses CX and MX power domains while the CDSPs
add an NSP domain on top of that.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260729023508.879752-3-shengchao.guo@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260724182858.1868271-6-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260724182858.1868271-5-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260724182858.1868271-4-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <konrad.dybcio@oss.qualcomm.com>
Fixes: 29814986b8 ("remoteproc: qcom_q6v5_pas: add support for dtb co-firmware loading")
Cc: stable@vger.kernel.org
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260724182858.1868271-3-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260724182858.1868271-2-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The ADSP found on Eliza SoC is actually fully compatible with the ones
from SM8750 class. So add the SM8550 compatible as fallback, just like
the rest from the SM8750 class SoCs.
Fixes: 88ddafb01e ("arm64: dts: qcom: eliza: Describe the ADSP and USB related nodes")
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260722-dts-qcom-eliza-fix-adsp-binding-v2-2-e1e98ae15533@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The ADSP PAS found on Eliza SoC looks fully compatible with SM8750, which
can fallback to SM8550 except for the extra interrupt ("shutdown-ack").
So document its bindings in the SM8550 schema instead.
Fixes: 7cf2f07f94 ("dt-bindings: remoteproc: qcom,milos-pas: Document Eliza ADSP")
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260722-dts-qcom-eliza-fix-adsp-binding-v2-1-e1e98ae15533@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260722-remoteproc-eliza-cdsp-v4-2-04c6eee70cb1@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Document compatible string for the CDSP Peripheral Authentication Service
on the Eliza SoC. It is not compatible with any other.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260722-remoteproc-eliza-cdsp-v4-1-04c6eee70cb1@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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: 3cc889eb83 ("remoteproc: qcom: q6v5: Avoid setting smem bit in case of crash shutdown")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260723-q6v5-host-side-crash-v1-1-23bd53db90a7@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <bjorn.andersson@oss.qualcomm.com>
Reviewed-by: Pradnya Dahiwale <pradnya.dahiwale@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260723-rproc-rmmod-not-crashing-v1-3-546dfd5de0e6@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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: 8afd519c34 ("remoteproc: add rproc_report_crash function to notify rproc crashes")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Reviewed-by: Pradnya Dahiwale <pradnya.dahiwale@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260723-rproc-rmmod-not-crashing-v1-2-546dfd5de0e6@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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: 5e6a0e0527 ("remoteproc: core: Move state checking to remoteproc_core")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260723-rproc-rmmod-not-crashing-v1-1-546dfd5de0e6@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Convert Texas Instruments Wakeup M3 Remote Processor from text to Dt
schema. Add optional resets and reset-names property which was missing
from legacy binding. make ti,hwmods deprecated as it no longer needed,
it is kept to support older board files without ti,sysc.
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20260719-ti-wkup_m3-v1-1-848a95b401a5@gmail.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Add a remoteproc driver for AMD MicroBlaze/V soft-core processor
subsystems instantiated in programmable logic and using dual-port BRAM
for firmware storage and execution.
The driver parses the firmware memory window from the remoteproc device
node's reg property, interprets that address and size in the
processor-local address space, and then uses standard devicetree address
translation through the parent bus ranges property to obtain the
corresponding Linux-visible system physical address.
The resulting translated region is registered as the executable
remoteproc carveout and coredump segment.
The processor is controlled through an active-low reset GPIO and a
subsystem clock. The clock is enabled before reset is released, and the
processor is kept in reset until firmware loading completes.
The firmware-name property is optional, allowing firmware to be assigned
later through the remoteproc framework. Firmware images without a
resource table are also accepted.
Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
Link: https://lore.kernel.org/r/20260714202441.554065-3-ben.levinsky@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Describe an AMD MicroBlaze/V BRAM-based remote processor controlled
through the remoteproc framework.
The binding models a soft-core processor subsystem instantiated in AMD
programmable logic and using dual-port BRAM for firmware storage and
execution. The remoteproc device is represented as a child node whose
reg property describes the firmware memory window in the processor-local
address space. The parent bus node provides standard devicetree address
translation through ranges so Linux can access the same BRAM through the
system physical address space.
A clock input feeds the soft-core processor subsystem, and an active-low
reset GPIO holds the processor in reset until firmware loading completes.
The firmware-name property is optional.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
Link: https://lore.kernel.org/r/20260714202441.554065-2-ben.levinsky@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
SHM bridge creation is required to enable memory protection for both
remoteproc metadata and its memory region on Qualcomm SoCs like Glymur
running non-Gunyah based Hypervisors, unlike Kaanapali.
Having Glymur fall back to the Kaanapali binding is therefore incorrect
and breaks subsystem restart on Glymur.
Fix this by decoupling Glymur SoCCP PAS from Kaanapali and registering
it as its own binding.
Fixes: 8b54bacadc ("dt-bindings: remoteproc: qcom: Document pas for SoCCP on Kaanapali and Glymur platforms")
Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260709-glymur-soccp-v6-1-16f70227547d@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The DT schema core defines the type ($ref) of 'firmware-name' property
as string-array, so individual schemas do not need to. They also should
not redefine it to a single string, but instead just set number of
expected firmware names.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260712145718.126492-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Some Qualcomm SoCs using the generic PAS remoteproc driver (e.g.
Shikra) implement the BAM-DMUX protocol on the modem remoteproc to
expose network data channels. The hardware/firmware resources
required by the BAM-DMUX driver are described in an extra device
tree node below the modem remoteproc, with the compatible
"qcom,bam-dmux".
qcom_q6v5_mss.c already creates a platform device for this node
(commit 59983c74fc ("remoteproc: qcom_q6v5_mss: Create platform
device for BAM-DMUX")), but qcom_q6v5_pas.c has no equivalent logic,
so the bam-dmux node never probes on SoCs handled by this driver.
Mirror the qcom_q6v5_mss.c approach: create a platform device
specifically for the "qcom,bam-dmux" child node on probe, and
destroy it on remove. of_get_compatible_child() returns NULL when
the node is absent, and of_platform_device_create()/of_node_put()
are NULL-safe, so this is a no-op for the many PAS-based SoCs that
have no bam-dmux child.
Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260711-qcom-q6v5-pas-bam-dmux-v1-1-1e9231143b79@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
For rproc that doing attach, rproc_start_subdevices() is called only when
attach successfully. If rproc_report_crash() is called in the attach
function, rproc_boot_recovery()->rproc_stop()->rproc_stop_subdevices()->
glink_subdev_stop() could be called and cause NULL pointer dereference:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000300
Mem abort info:
...
pc : qcom_glink_smem_unregister+0x14/0x48 [qcom_glink_smem]
lr : glink_subdev_stop+0x1c/0x30 [qcom_common]
...
Call trace:
qcom_glink_smem_unregister+0x14/0x48 [qcom_glink_smem] (P)
glink_subdev_stop+0x1c/0x30 [qcom_common]
rproc_stop+0x58/0x17c
rproc_trigger_recovery+0xb0/0x150
rproc_crash_handler_work+0xa4/0xc4
process_scheduled_works+0x18c/0x2d8
worker_thread+0x144/0x280
kthread+0x124/0x138
ret_from_fork+0x10/0x20
Code: a9be7bfd 910003fd a90153f3 aa0003f3 (b9430000)
---[ end trace 0000000000000000 ]---
Introduce "subdevs_started" flag to indicate rproc_start_subdevices() has
been called successfully. Ensure subdevices are only stopped if they have
been started.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260623-rproc-attach-issue-v3-2-8e24310707ce@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <jingyi.wang@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260623-rproc-attach-issue-v3-1-8e24310707ce@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Document compatible strings for the ADSP and CDSP Peripheral Authentication
Services on the Qualcomm Maili SoC. Both are compatible with the Qualcomm
SM8550 PAS and can fallback to SM8550 except for one additional interrupt
("shutdown-ack"). For CDSP, similar to Kaanapali, "global_sync_mem" is
not managed by the kernel.
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260615-remoteproc-v1-1-67721b4b052a@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The handover interrupt is expected to be consumed once during each prepare
cycle. If the remote processor keeps signalling handover after the first
event, qcom_q6v5 currently logs the duplicate interrupt repeatedly while
leaving the IRQ enabled.
Track the handover IRQ enable state explicitly and route all handover IRQ
enable/disable operations through idempotent helpers. Request the handover
IRQ with IRQF_NO_AUTOEN so it is only enabled through the helper during
prepare. The handover handler disables it after marking handover as issued,
while unprepare disables and synchronizes it before checking whether
handover was issued.
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260612-rproc-q6v5-handover-irq-one-shot-v1-1-bb688f4446b3@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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: cd9fc8f1b3 ("remoteproc: qcom: Pass ssr_name to glink subdevice")
Signed-off-by: Uday Khare <udaykhare77@gmail.com>
Link: https://lore.kernel.org/r/20260618132054.11010-1-udaykhare77@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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: 4fe236a1d0 ("remoteproc: qcom_q6v5_mss: Add MDM9607")
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260706-qcom-q6v5-mss-mdm9607-ssctl-id-v1-2-f59e728af621@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <stephan.gerhold@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260706-qcom-q6v5-mss-mdm9607-ssctl-id-v1-1-f59e728af621@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
SHM bridge creation is required to enable memory protection for both
remoteproc metadata and its memory region on Qualcomm SoCs running
non-Gunyah based Hypervisors. We currently rely on the iommu property
being present in the remoteproc nodes to detect this.
However, this doesn't cover for cases where the remoteproc does a late
attach, like SoCCP, and for remoteprocs like OOBM SS (Out of Band
Management Sub-system) that doesn't have an iommu in front of it. In the
former case, any attempt to create new mappings would fail with EEXIST
as they are already setup by the bootloader when the SoCCP is brought
out of reset, and unmapping them to create fresh mappings leads to faults
since SoCCP could have active transactions on the bus. In the latter case,
absence of iommu will be caught by the has_iommu flag, and SHM bridge
creation will be skipped.
Fix this by introducing a needs_tzmem flag which would cover for the
above edge cases by serving as an alternate trigger to the PAS helpers
to ensure that SHM bridge is established.
Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260707-glymur-soccp-v5-1-053993f0c6fe@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <val@packett.cool>
Fixes: 65991ea8a6 ("remoteproc: qcom_wcnss: Handle platforms with only single power domain")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Fixes: 65991ea8a6 ("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 <andersson@kernel.org>
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: f22eedff28 ("remoteproc: qcom: Add support for memory sandbox")
Signed-off-by: Felix Gu <gu_0233@qq.com>
Link: https://lore.kernel.org/r/tencent_EDC2253D3B1C22217E1259E07765D269100A@qq.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Select PAS generic service driver to enable support for multiple PAS
backends like OP-TEE in addition to SCM.
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260702115835.167602-8-sumit.garg@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Switch qcom_wcnss client driver over to generic PAS TZ APIs. Generic PAS
TZ service allows to support multiple TZ implementation backends like QTEE
based SCM PAS service, OP-TEE based PAS service and any further future TZ
backend service.
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260702115835.167602-7-sumit.garg@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Switch qcom_q6v5_mss client driver over to generic PAS TZ APIs. Generic PAS
TZ service allows to support multiple TZ implementation backends like QTEE
based SCM PAS service, OP-TEE based PAS service and any further future TZ
backend service.
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260702115835.167602-6-sumit.garg@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Switch qcom_q6v5_pas client driver over to generic PAS TZ APIs. Generic PAS
TZ service allows to support multiple TZ implementation backends like QTEE
based SCM PAS service, OP-TEE based PAS service and any further future TZ
backend service.
Since qcom_q6v5_pas depends on MDT loader for PAS firmware loading, it
has to be switched over to generic PAS APIs in this commit to avoid any
build issues.
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260702115835.167602-5-sumit.garg@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add Sumit Garg as the maintainer for the Qualcomm generic Peripheral
Authentication Service (PAS) as well as the PAS TEE backend driver.
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260702115835.167602-15-sumit.garg@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add support for Peripheral Authentication Service (PAS) driver based
on TEE bus with OP-TEE providing the backend PAS service implementation.
The TEE PAS service ABI is designed to be extensible with additional API
as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future
extensions of the PAS service needed while still maintaining backwards
compatibility.
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260702115835.167602-4-sumit.garg@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
With the availability of generic PAS service, let's add SCM calls as
a backend to keep supporting legacy QTEE interfaces. The exported
qcom_scm* wrappers will get dropped once all the client drivers get
migrated as part of future patches.
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260702115835.167602-3-sumit.garg@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Qcom platforms has the legacy of using non-standard SCM calls
splintered over the various kernel drivers. These SCM calls aren't
compliant with the standard SMC calling conventions which is a
prerequisite to enable migration to the FF-A specifications from Arm.
OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't
support these non-standard SCM calls. And even for newer architectures
using S-EL2 with Hafnium support, QTEE won't be able to support SCM
calls either with FF-A requirements coming in. And with both OP-TEE
and QTEE drivers well integrated in the TEE subsystem, it makes further
sense to reuse the TEE bus client drivers infrastructure.
The added benefit of TEE bus infrastructure is that there is support
for discoverable/enumerable services. With that client drivers don't
have to manually invoke a special SCM call to know the service status.
So enable the generic Peripheral Authentication Service (PAS) provided
by the firmware. It acts as the common layer with different TZ
backends plugged in whether it's an SCM implementation or a proper
TEE bus based PAS service implementation.
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260702115835.167602-2-sumit.garg@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Make sure to drop the reference taken to the SCP device when attempting
to look up its driver data before the driver has been bound.
Note that holding a reference to a device does not prevent its driver
data from going away.
Fixes: 63c13d61ea ("remoteproc/mediatek: add SCP support for mt8183")
Cc: stable@vger.kernel.org # 5.6
Cc: Erin Lo <erin.lo@mediatek.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20260706065614.389412-1-johan@kernel.org
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
devm_reset_control_get_exclusive() does not return NULL (only valid
clock or ERR pointer in case for non-optional get), so simplify the code
to drop redundant IS_ERR_OR_NULL().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://lore.kernel.org/r/20260705172353.119031-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Remote processor will report the crash reason via the resource table
and notify the host via mailbox notification. The host checks this
crash reason on every mailbox notification from the remote and report
to the rproc core framework. Then the rproc core framework will start
the recovery process.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20260630004806.3835488-3-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Current attach on recovery mechanism loads the clean resource table
during recovery, but doesn't re-allocate the resources. RPMsg
communication will fail after recovery due to this. Fix this
incorrect behavior by doing the full detach and attach of remote
processor during the recovery. This will load the clean resource table
and re-allocate all the resources, which will set up correct vring
information in the resource table.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20260630004806.3835488-2-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
The SoC Control Processor (SoCCP) is small RISC-V MCU that controls
USB Type-C, battery charging and various other functions on Qualcomm SoCs.
It provides a solution for control-plane processing, reducing per-subsystem
microcontroller reinvention. Add support for SoCCP PAS loader on Kaanapali
platform.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Hawi SoC
Link: https://lore.kernel.org/r/20260623-knp-soccp-v7-6-1ec7bb5c9fec@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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 <gokul.krishnakumar@oss.qualcomm.com>
Signed-off-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
Tested-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260623-knp-soccp-v7-5-1ec7bb5c9fec@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Document SoCCP remote processor used on Qualcomm Hawi and Maili SoC which
is fully compatible with Kaanapali.
Co-developed-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260623-knp-soccp-v7-4-1ec7bb5c9fec@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Document the component used to boot SoCCP on Kaanapali SoC and add
compatible for Glymur SoCCP which could fallback to Kaanapali. Extend
the "qcom,smem-states", "qcom,smem-state-names" in the pas-common
and add maxItems constraints for SMEM properties in the documents
that reference to pas-common.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260623-knp-soccp-v7-3-1ec7bb5c9fec@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Move interrupts and interrupt-names list out of pas-common since they
will be redefined differently for Kaanapali SoCCP.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260623-knp-soccp-v7-2-1ec7bb5c9fec@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
