| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux
Pull remoteproc updates from Bjorn Andersson:
- Add Qualcomm QMI Thermal Mitigation Device support for PAS-managed
remote processors, with cooling device bindings and configurations
for Hamoa, Kodiak, Lemans, Talos, Monaco, and Shikra CDSP and modem
subsystems as applicable.
- Add per-power-domain proxy performance states for Hawi CDSP and
update Hawi, Maili, and SDX75 PAS compatible bindings and the SDX75
device tree. Correct the Qualcomm ADSP startup timeout.
- Fetch auto-boot firmware only once and synchronize boot work with
device removal. Bound ELF section header accesses, improve trace
diagnostics, and update coredump configuration documentation.
- Set 48-bit DMA masks for TI K3 DSP and R5 remote processors, correct
mailbox message types, and enable compile testing for more TI
drivers. Fix i.MX address range boundary checks and DSP runtime PM
ordering, and simplify mailbox notification handling.
- Harden Xilinx mailbox setup and teardown and avoid sending
notifications when the transmit queue is full. Propagate STM32
optional IRQ lookup errors and correct the MediaTek MT8188 SCP
register binding.
* tag 'rproc-v7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: (33 commits)
remoteproc: qcom_q6v5_pas: Add QMI TMD cooling support for Shikra
remoteproc: virtio: Remove stray white space
remoteproc: virtio: Replace kmemdup with kmemdup_array
remoteproc: virtio: Add vdev_to_rsc() helper
remoteproc: core: Fetch the auto-boot firmware only once
remoteproc: xlnx: fix typecast warnings
remoteproc: qcom_q6v5_pas: enable QMI TMD cooling support
remoteproc: qcom: pas: add support for TMD thermal cooling devices
soc: qcom: Add QMI TMD support for remote thermal mitigation
dt-bindings: remoteproc: qcom,pas: add #cooling-cells property
remoteproc: qcom_q6v5_pas: add per-PD proxy performance states for Hawi CDSP
dt-bindings: remoteproc: qcom,sm8550-pas: make qcom,hawi-cdsp-pas standalone
arm64: dts: qcom: sdx75: Use SM8650 MPSS as fallback compatible
dt-bindings: remoteproc: qcom,sm8550-pas: Make SDX75 MPSS fallback to SM8650
dt-bindings: remoteproc: qcom,sm8550-pas: Add Hawi and Maili MPSS as SM8650 fallback
dt-bindings: remoteproc: Fix MT8188 SCP regs
remoteproc: Use %p for pointer formatting
remoteproc: Add compile testing for additional TI drivers
remoteproc: k3-dsp: Fix usage of omap_mbox_message and mbox_msg_t
remoteproc: k3: Include what we need and only what we need
...
|
|
Add QMI TMD instance IDs and cooling device name arrays for CDSP
and MPSS subsystems on Shikra to enable thermal mitigation support.
Signed-off-by: Dipa Ramesh Mantre <dipa.mantre@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260911-shikra_qmi_tmd-v1-1-96c1cca82f30@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Pull vhost,virtio updates from Michael Tsirkin:
"This adds CPR support for vhost.
Plus some fixes, notably for a host of races we had when callback fire
around device reset"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
tools/virtio: add missing device-id/virtio.h wrapper header
vhost/vsock: add VHOST_RESET_OWNER ioctl
vhost: synchronize with RCU readers when freeing workers
vhost/vsock: re-scan TX virtqueue on device start
vhost/vsock: suppress EHOSTUNREACH fast-fail during CPR pause
vhost/vsock: split out vhost_vsock_drop_backends helper
virtio_pci: drop callback sync on reset
virtio_pci_modern: move avq cleanup from reset to del_vqs
virtio: synchronize callbacks after device reset
virtio_vdpa: implement synchronize_cbs()
platform/mellanox: mlxbf-tmfifo: implement synchronize_cbs()
um: virtio_uml: implement synchronize_cbs()
remoteproc: implement synchronize_cbs() for virtio devices
virtio_ccw: always take irq_lock in the classic interrupt handler
virtio_ccw: fix synchronize_cbs() after interrupt fallback
|
|
Remove a stray white space in function definition. No functional
changes.
Signed-off-by: Francesco Valla <francesco@valla.it>
Link: https://lore.kernel.org/r/20261010-remoteproc_rework-v1-3-cc30dc34d866@valla.it
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Let kmemdup_array take care of multiplication and overflows.
While at it, add blank lines in the same function for readability.
Signed-off-by: Francesco Valla <francesco@valla.it>
Link: https://lore.kernel.org/r/20261010-remoteproc_rework-v1-2-cc30dc34d866@valla.it
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Instead of repeating the table+offset math in every function that needs
to access the resource linked to a vdev, add a simple helper function
for that to simplify the code a bit.
No functional changes.
Signed-off-by: Francesco Valla <francesco@valla.it>
Link: https://lore.kernel.org/r/20261010-remoteproc_rework-v1-1-cc30dc34d866@valla.it
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Auto-boot for an always-on remote processor registers an asynchronous
request_firmware_nowait() whose callback, rproc_auto_boot_callback(),
calls rproc_boot() first and only releases the fetched image at the
very end of the callback. rproc_boot() does not take this image as an
argument: it fetches the very same image again with a synchronous
request_firmware(), so every auto-boot reads the firmware image twice
and allocates the buffer twice; on kernels with the sysfs fallback
enabled, the uevent round-trip is repeated as well.
The asynchronous request exists only so that rproc_add() does not
block on the filesystem read; the image it fetches is never used.
The core already defers rproc_boot() to a worker for detached
processors (attach_work). Reuse that worker for offline processors
too and drop the asynchronous firmware request: rproc_boot() fetches
the image exactly once and dispatches between a firmware boot and
an attach based on the processor state. The work is renamed to
boot_work to match its widened role.
commit 400e64df6b23 ("remoteproc: add framework for controlling remote
processors") noted back in 2011 that "we must wait until it completes
before we try to unregister the device". rproc_del() now does exactly
that: it waits for the boot work with cancel_work_sync(), which also
closes the theoretical window in which a pending attach work could
outlive the rproc instance.
The changed fallback behaviour only matters for legacy
configurations. udev dropped its userspace firmware loader back in
2014, as recorded in
Documentation/driver-api/firmware/fallback-mechanisms.rst, and the
kernel has documented since commit 02c399306826 ("firmware_loader:
enhance Kconfig documentation over FW_LOADER") that "Linux no longer
relies on or uses a fallback mechanism in userspace". Auto-boot now
uses the same synchronous fallback semantics as every other explicit
boot source (sysfs, cdev).
Signed-off-by: Yonghao Zhang <hyz3367@gmail.com>
Link: https://lore.kernel.org/r/20261001081056.38293-1-hyz3367@gmail.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Fix following sparse warnings by using __force attribute:
sparse warnings: (new ones prefixed by >>)
drivers/remoteproc/xlnx_r5_remoteproc.c:571:20: sparse: sparse:
cast removes address space '__iomem' of expression
drivers/remoteproc/xlnx_r5_remoteproc.c:749:17: sparse: sparse:
cast removes address space '__iomem' of expression
drivers/remoteproc/xlnx_r5_remoteproc.c:773:24: sparse: sparse:
cast removes address space '__iomem' of expression
drivers/remoteproc/xlnx_r5_remoteproc.c:797:25: sparse: sparse:
cast removes address space '__iomem' of expression
>> drivers/remoteproc/xlnx_r5_remoteproc.c:837:49: sparse: sparse:
incorrect type in initializer (different address spaces) @@ expected
void *rsc_offset @@ got void [noderef] __iomem * @@
drivers/remoteproc/xlnx_r5_remoteproc.c:837:49: sparse:
expected void *rsc_offset
drivers/remoteproc/xlnx_r5_remoteproc.c:837:49: sparse: got
void [noderef] __iomem *
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608190009.uCbYi1Y5-lkp@intel.com/
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20260828155846.2883035-1-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Enable Thermal Mitigation Device (TMD) support for PAS-managed CDSP and
modem remote processors on platforms that expose the QMI TMD service.
This adds per-platform TMD configuration in qcom_q6v5_pas for:
- Hamoa (X1E80100) CDSP
- Kodiak CDSP and modem
- Lemans (SA8775P) CDSP
- Talos CDSP
- Monaco CDSP
For each remoteproc, the configured TMD QMI instance ID is used to bind to
the TMD service running on that subsystem (e.g. CDSP: 0x43, modem: 0x0).
The driver then uses the corresponding TMD endpoint names ("cdsp_sw",
"pa", "modem") for cooling-device registration.
QMI TMD identifies mitigation endpoints by name, while DT thermal bindings
reference cooling devices by id. This change provides the mapping
between DT cooling indices and QMI TMD names, allowing remoteproc nodes
with #cooling-cells to act as cooling devices in the thermal framework.
With this in place, thermal policies can request mitigation from CDSP and
modem subsystems via QMI under thermal pressure.
Reviewed-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260809-b4-qmi-tmd-v8-4-b15d47adc379@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Register Thermal Mitigation Devices (TMDs) for PAS-managed remote
processors to enable thermal throttling through QMI.
This allows the thermal framework to request mitigation when remote
subsystems such as modem and CDSP contribute to thermal pressure.
Reviewed-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260809-b4-qmi-tmd-v8-3-b15d47adc379@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The proxy power domain enable path requests INT_MAX performance
state for every proxy PD. On Hawi, the NSP proxy power domain's
RPMH power domain has no OPP at INT_MAX, while CX and MXC accept
INT_MAX, mapping to their maximum supported level.
Introduce a proxy_pd_performance_states array in qcom_pas_data
to allow per-PD RPMH levels to be declared explicitly. Platforms
that omit this field retain the existing INT_MAX behaviour.
Add Hawi CDSP remoteproc support with the following proxy PD
performance states:
CX: RPMH_REGULATOR_LEVEL_TURBO
MXC: RPMH_REGULATOR_LEVEL_TURBO
NSP: RPMH_REGULATOR_LEVEL_NOM
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Tested-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260914084312.3812408-3-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Commit 276ec9934231e ("remoteproc: replace "%p" with "%pK"") introduced
the %pK in order to not leak kernel pointers.
Since commit ad67b74d2469d ("printk: hash addresses printed with
%p") pointers are hashed by default and the behaviour can be controller
by `hash_pointers' boot argument.
The policy on %p is to not introduce new ones.
Removing %pK makes it possible to remove its handling from the library.
I doubt printing the address of struct fw_rsc_hdr with an unknown type
brings any value. The va is printed already in debug output in other
places as %p so it makes probably no difference to remove it from
rproc_carveouts_show().
Use %p instead %pK for rproc_mem_entry::va, remove the address of the
unknown type.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20260918104628.jqQhAlF-@linutronix.de
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Many Remoteproc drivers, including K3, can and are built for compile
testing. The WKUP_M3, Keystone, and DA8xx can be also, enable this here.
Doing this exposes a compile warning on 64bit platforms as size_t changes
size, use the correct printf format specifier for size_t.
We cannot compile test for OMAP_REMOTEPROC due to dependency on OMAP
clock framework. But while here fix up the Kconfig help text which claims
this driver only works for OMAP4, when it really works across several
OMAP-class devices.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20260904195634.2275867-3-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The type of message sent using omap-mailbox is always u32. The definition
of mbox_msg_t is uintptr_t which is wrong as that type changes based on
the architecture (32bit vs 64bit). Make the type fixed to u32.
This then means we need to fix the helper macro omap_mbox_message so it
doesn't cast to u32 twice. What this macro should be doing is converting
from the message type returned from the mailbox framework into the
omap-mailbox type. When fixing this we should add a macro for the other
direction (from omap-mailbox type to something that can be used with
mbox_send_message).
After these changes, make use of the new macros as appropriate.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20260904195634.2275867-2-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The header ti_k3_common.h uses several definitions in headers it does not
include itself, this makes users of this header responsible for including
the right headers first. Instead include what we need here. Then go and
remove some headers that we do not use from the K3 Remoteproc drivers.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
Tested-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20260904195634.2275867-1-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
rproc_trace_read() (in remoteproc_debugfs.c) prints the name of a
trace buffer whose device address could not be resolved, but nothing
ever assigns trace_mem.name, so that the diagnostics always prints
an empty string:
Trace not available
Copy the generated "trace%d" name into the memory entry, so the
diagnostics identifies the buffer failed to translate.
Fixes: a987e6b91a5a ("remoteproc: fix trace buffer va initialization")
Assisted-by: Claude-Code:glm-5.3
Signed-off-by: Yonghao Zhang <hyz3367@gmail.com>
Link: https://lore.kernel.org/r/20260911081810.740028-1-hyz3367@gmail.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The documentation of the 'coredump' sysfs entry still advertises a
"default" configuration option and describes it as the default value
of the entry. Both date back to before the option was renamed to
"enabled" and the default configuration was changed to "disabled".
Update the comment to describe the three options the store callback
actually accepts, "disabled", "enabled" and "inline", along with the
real default value, and fix the coredump_show() comment which wrongly
claims the configuration is exposed via debugfs.
Assisted-by: Claude-Code:glm-5.3
Signed-off-by: Yonghao Zhang <hyz3367@gmail.com>
Link: https://lore.kernel.org/r/20260911030944.1645477-1-hyz3367@gmail.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Platform drivers invoke rproc_vq_interrupt() from hard-IRQ handlers,
threaded handlers, and work items. Because rpmsg callbacks may sleep,
the virtio core's synchronize_rcu() fallback does not synchronize with
callbacks across all these contexts. A device reset can therefore
complete while a callback is still running.
Add an SRCU domain per rproc. Protect both the queue lookup and
vring_interrupt() with it, and synchronize the domain in the new hook.
__rproc_virtio_del_vqs() can race with rproc_vq_interrupt() too. Clear
all queue pointers and synchronize the SRCU domain before freeing the
queues, so callers that already found a queue can finish using it.
Read rvring->vq once to avoid a second load after deletion starts.
The SRCU domain has the same lifetime as struct rproc. Its cleanup can
sleep, so document that rproc_free() and rproc_put() must not drop the
last reference from atomic context.
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260908053817.26065-4-kmehltretter@gmail.com>
|
|
The address range checks in imx_rproc_da_to_sys() and
imx_rproc_da_to_va() use a strict comparison for the exclusive end
address of the requested range.
As a result, a valid request that ends exactly at the end of an address
translation or mapped memory region is rejected. For a region
[start, start + size), a request [addr, addr + len) is contained when:
addr >= start && addr + len <= start + size
This occurs when a loadable ELF segment fills an entire mapped memory
region. This can be produced by a linker script that extends the
resource table section to the end of its designated region:
.resource_table :
{
. = ALIGN(8);
KEEP(*(.resource_table)) /* Resource table */
. = ALIGN(8);
. = ORIGIN(m_rsc_tbl) + LENGTH(m_rsc_tbl);
} > m_rsc_tbl =0x00
This produces a ELF program header like:
LOAD 0x010000 0xa4220000 0xa4220000 0x01000 0x01000 R 0x1000
In this case, the segment size matches the mapped region size exactly,
causing the address translation to fail with:
bad phdr da 0xa4220000 mem 0x1000
Rework the upper-bound checks to allow ranges ending exactly at the region
boundary while guarding against integer overflow.
Fixes: a0ff4aa6f010 ("remoteproc: imx_rproc: add a NXP/Freescale imx_rproc driver")
Signed-off-by: Marcel Hofmann <marcel.hofmann@ingenics-digital.com>
Tested-by: Peng Fan <peng.fan@nxp.com> #i.MX95-19x19-EVK
Link: https://lore.kernel.org/r/20260827123136.438798-1-marcel@hofmania.de
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The prepare callback publishes DSP carveouts before acquiring the
runtime-PM reference that establishes required clocks and mailbox state.
A PM failure therefore leaves the prepare transaction partially
published.
Acquire runtime PM first and drop that reference if carveout
construction fails, so a failed prepare does not add resources before
its hardware prerequisite.
Fixes: ec0e5549f358 ("remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MX")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://lore.kernel.org/r/20260830133310.6926-1-pengpeng@iscas.ac.cn
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Only write a new message to the tx mbox queue if slot is available in
the tx queue. If queue is full, then do not send new mbox notification.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20260826173901.2329068-2-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
zynqmp_r5_setup_mbox() installs zynqmp_r5_mb_rx_cb() as the mailbox RX
callback before requesting the mailbox channels, but initializes
ipi->mbox_work only after both channels have been requested. Once the RX
channel is active, a notification delivered before the late INIT_WORK()
would make the callback queue an uninitialized work item.
Initialize the work item before requesting channels. Also drain the work
before freeing the mailbox state, after the channels have been released so
no new callbacks can queue it. Use the same drain before freeing ipi from
the channel request error paths, since the callback is already published
there as well.
This issue was found by our static analysis tool and then confirmed by
manual review of the mailbox setup sequence. The callback is published
before the channel requests complete, so the work item should be ready
before the mailbox provider can invoke it.
A QEMU PoC modeled a mailbox notification delivered after the RX callback
became reachable but before the delayed INIT_WORK(). DEBUG_OBJECTS reported
queueing an uninitialized work item from the zynqmp_r5_setup_mbox() path.
This is sent as an RFC because the practical trigger depends on the ZynqMP
IPI mailbox provider and firmware delivery timing. If the provider cannot
invoke the RX callback until after setup returns, this is a defensive
lifecycle cleanup rather than a reachable race on current systems.
Fixes: 5dfb28c257b7 ("remoteproc: xilinx: Add mailbox channels for rpmsg")
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Link: https://lore.kernel.org/r/20260818101201.1603947-1-runyu.xiao@seu.edu.cn
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The imx-mailbox driver moved the callback invocation into the threaded
IRQ handler. This means the callback is invoked in preemptible context
and there is no need to schedule the kworker for the
imx_rproc_notified_idr_cb() invocation.
This was tested with the rpmsg-tty driver on imx93.
Remove the workqueue handling and invoke the imx_rproc_notified_idr_cb()
callback directly.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20260813-imx_mbox_rproc-v6-1-6903a93b0456@linutronix.de
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
platform_get_irq_optional() returns a positive IRQ number on success or
a negative error code on failure. For an optional IRQ, -ENXIO indicates
that no IRQ is available, while other errors should be propagated.
Instead of only checking for -EPROBE_DEFER, propagate all error codes
returned by platform_get_irq_optional() other than -ENXIO, so that
failures are properly reported to the caller.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Link: https://lore.kernel.org/r/20260810051907.27136-1-phucduc.bui@gmail.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The C6x DSP can address 48-bit memory space through the Region Address
Translator (RAT) unit, and the C7x DSP has a native 48-bit address bus.
RAT is usually programmed by the firmware itself. Configure the
remoteproc device DMA mask to 48 bits to enable full addressing
capability for DMA operations.
Signed-off-by: Rahul T R <r-ravikumar@ti.com>
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20260727062851.2934443-3-b-padhi@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The K3 R5F cores can address 48-bit memory space through the Region
Address Translator (RAT) unit. RAT is usually programmed from the
firmware itself. Configure the remoteproc device DMA mask to 48 bits to
enable full addressing capability for DMA operations.
Signed-off-by: Rahul T R <r-ravikumar@ti.com>
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Link: https://lore.kernel.org/r/20260727062851.2934443-2-b-padhi@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The rproc_elf_sanity_check() only checks the image is big enough to hold
one section header. But find_table() walks e_shnum of them, and first
dereferences the header at e_shstrndx to locate the section name table.
Both fields are u16 and both come from the image, so an e_shstrndx of
65535 reads about 4 MB past the buffer.
The commit 9f9967fed9d0 ("soc: qcom: mdt_loader: Ensure we don't read
past the ELF header") added the same check to the MDT loader, and says
the header "is sanitized beforehand" under remoteproc. That is what this
patch makes true.
Check e_shoff against the image size first, so the two bounds can use
size_add() without an e_shoff above SIZE_MAX wrapping on 32-bit. The
bounds are separate because e_shnum may be zero while find_table() still
reads the e_shstrndx header.
Fixes: 400e64df6b23 ("remoteproc: add framework for controlling remote processors")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://lore.kernel.org/r/20260724025322.2341205-1-sammiee5311@gmail.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
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 <vignesh.viswanathan@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/20260819-rproc_dtb_fix-v1-1-cb6be7f93bc9@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
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 <smostafa@google.com>
Link: https://lore.kernel.org/r/20260827203055.640116-1-smostafa@google.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
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 <phollinsky@holtechnik.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260821081540.89137-1-phollinsky@holtechnik.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
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 <stephan.gerhold@linaro.org>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260801011731.1084591-1-shengchao.guo@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
adsp_start() computes 5 * HZ, an already-converted jiffies count, and
passes it into msecs_to_jiffies(), which expects milliseconds --
reinterpreting the value and shrinking the intended timeout. Every
other caller (q6v5_start() in qcom_q6v5_mss.c, qcom_pas_start() in
qcom_q6v5_pas.c) passes msecs_to_jiffies(5000) directly, matching
qcom_q6v5_wait_for_start()'s kerneldoc, which documents @timeout as
already being in jiffies.
On CONFIG_HZ=250 this shrinks the intended 5 second timeout to
~1.25 seconds, causing a DSP that legitimately takes 2-3 seconds to
signal ready to be spuriously torn down as a boot failure.
Fix by passing msecs_to_jiffies(5000) directly, matching every other
caller.
Signed-off-by: Anup Vishwakarma <anup.vishwakarma@oss.qualcomm.com>
Fixes: dc160e449122 ("remoteproc: qcom: Introduce Non-PAS ADSP PIL driver")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260831-b4-adsp_start_jiffies_fix_upstream-v1-1-9f8cf85ea220@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
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 <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260729023508.879752-4-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: 29814986b82e ("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>
|
|
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>
|
|
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 <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: 8afd519c3470 ("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: 5e6a0e05270e ("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>
|
|
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
devm_request_*_irq()"), devm_request_irq() and devm_request_threaded_irq()
automatically log detailed error messages on failure. Remove the
now-redundant driver-specific dev_err() and dev_err_probe() calls.
Signed-off-by: Pan Chuang <panchuang@vivo.com>
Acked-by: Paul Cercueil <paul@crapouillou.net> # Ingenic
Link: https://lore.kernel.org/r/20260717065224.600593-1-panchuang@vivo.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>
|
|
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 59983c74fc42 ("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>
|
|
Ensure crash_handler work is cancelled before tearing down rproc resources
to avoid accessing freed memory.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260623-rproc-attach-issue-v3-3-8e24310707ce@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>
|
|
schedule_work()
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>
|
|
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>
|
