Add the CDSP, LPAICP and MPSS Peripheral Authentication Service support
for the Qualcomm Shikra SoC.
Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260521-shikra-rproc-v3-2-2fca0bbe1ad7@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Various names for Qualcomm as a company are used in user-visible config
options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified
"Qualcomm" so it will be easier for users to identify the options when
for example running menuconfig.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260422083334.84294-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Free allocated minidump_region 'name' in qcom_add_minidump_segments()
when failing before adding the region to 'dump_segments'. Otherwise,
the 'name' is not tracked and is never freed by qcom_minidump_cleanup().
Return error when adding to 'dump_segments' fails.
Cc: stable@vger.kernel.org # v5.11
Fixes: 8ed8485c4f ("remoteproc: qcom: Add capability to collect minidumps")
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260318-rproc-memleak-v2-1-ade70ab858f2@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The wcss_q6_bcr_reset used on QCS404, and wcss_q6_reset used on IPQ
are the same. "BCR reset" is redundant, and likely a mistake. Use the
documented "wcss_q6_reset" instead. Drop ".wcss_q6_reset_required"
from the descriptor, since all targets now need it.
This changes the bindings expectations, however, it actually fixes the
driver to consume the intended ones (qcom,q6v5.txt), which lists
"wcss_q6_reset" and *not* "wcss_q6_bcr_reset"
Fixes: 0af65b9b91 ("remoteproc: qcom: wcss: Add non pas wcss Q6 support for QCS404")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Link: https://lore.kernel.org/r/20251208223315.3540680-1-mr.nuke.me@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The remoteproc framework has capability to start (or attach to) the remote
processor automatically if auto boot flag is set by the driver during
probe. If the 'firmware-name' property is available for the remoteproc
node, then that firmware will be loaded and started during auto boot. If
the remote core is started by the bootloader then during auto-boot
remoteproc framework will try to attach to the remote processor.
The current architecture allocates and adds the remoteproc instance before
all the hardware such as sram, mbox, TCM is initialized. This design has
to be changed for auto boot to work. So, rename zynqmp_r5_rproc_add()
function to zynqmp_r5_rproc_alloc() and move adding the remoteproc
instance at the end of cluster initialization. This makes sure that all
the required hardware is initialized before starting the remote
processor.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20260527051611.194844-3-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Bindings can be deprecated and driver should not include bindings
headers directly. Instead define needed constants in the driver.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20260508174006.3783082-1-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
As currently there are maybe multiple remote processors, so change from
using fixed name to using device node name as remote processor name in
order to make them can be distinguished by through of name in sys
filesystem.
Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20260508032016.27716-1-Jiafei.Pan@nxp.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Replace the open-coded resource table iteration loop in
rproc_handle_resources() with the rsc_table_for_each_entry() helper.
The remoteproc-specific dispatch logic (vendor resource handling via
rproc_handle_rsc(), RSC_LAST bounds check, handler table lookup) is
moved into a local callback rproc_handle_rsc_entry(), keeping the
iteration mechanics in one canonical place.
The callback receives the payload offset within the table so that
handlers which write back into the resource table (e.g.
rproc_handle_carveout() recording a dynamically allocated address via
rsc_offset) continue to work correctly.
No functional change.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260506050107.1985033-3-mukesh.ojha@oss.qualcomm.com
The remote state is set to RPROC_DETACHED if the resource table is found
in the memory. However, this can be wrong if the remote is not started,
but firmware is still loaded in the memory. Use PM_GET_NODE_STATUS call
to the firmware to request the state of the RPU node. If the RPU is
actually out of reset and running, only then move the remote state to
RPROC_DETACHED, otherwise keep the remote state to RPROC_OFFLINE.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Fixes: bca4b02ef9 ("remoteproc: xlnx: Add attach detach support")
Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20260428221855.313752-1-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Add basic remoteproc support for the i.MX94 M-core processors, including
address translation tables(dev addr is from view of remote processor,
sys addr is from view of main processor) and device configuration data for
the CM70, CM71, and CM33S cores.
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20260427-imx943-rproc-v4-3-68d7c7253acd@nxp.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Cortex-M[7,33] processors use a fixed reset vector table format:
0x00 Initial SP value
0x04 Reset vector
0x08 NMI
0x0C ...
...
IRQ[n]
In ELF images, the corresponding layout is:
reset_vectors: --> hardware reset address
.word __stack_end__
.word Reset_Handler
.word NMI_Handler
.word HardFault_Handler
...
.word UART_IRQHandler
.word SPI_IRQHandler
...
Reset_Handler: --> ELF entry point address
...
The hardware fetches the first two words from reset_vectors and populates
SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
Reset_Handler.
However, the ELF entry point does not always match the hardware reset
address. For example, on i.MX94 CM33S:
ELF entry point: 0x0ffc211d
hardware reset base: 0x0ffc0000 (default reset value, sw programmable)
Current driver always programs the reset vector as 0. But i.MX94 CM33S's
default reset base is 0x0ffc0000, so the correct reset vector must be
passed to the SM API; otherwise the M33 Sync core cannot boot successfully.
rproc_elf_get_boot_addr() returns the ELF entry point, which is not the
hardware reset vector address. Fix the issue by deriving the hardware reset
vector locally using a SoC-specific mask:
reset_vector = rproc->bootaddr & reset_vector_mask
The ELF entry point semantics remain unchanged. The masking is applied only
at the point where the SM reset vector is programmed.
Add reset_vector_mask = GENMASK_U32(31, 16) to the i.MX95 M7 configuration
so the hardware reset vector is derived correctly. Without this mask, the
SM reset vector would be programmed with an unaligned ELF entry point and
the M7 core would fail to boot.
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20260427-imx943-rproc-v4-2-68d7c7253acd@nxp.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
There is already an 'if REMOTEPROC' condition wrapping this config option,
making the 'depends on REMOTEPROC' statement a duplicate dependency
(dead code).
I propose leaving the outer 'if REMOTEPROC...endif' and removing the
individual 'depends on REMOTEPROC' statement.
This dead code was found by kconfirm, a static analysis tool for Kconfig.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Link: https://lore.kernel.org/r/20260417221337.286313-1-julianbraha@gmail.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Mark "data" argument in rpmsg_send() const, and perculate to related
drivers. Replace deprecated class_destroy() with class_unregister().
-----BEGIN PGP SIGNATURE-----
iQJCBAABCgAsFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmnhmuEOHGJqb3JuQGty
eW8uc2UACgkQCx85Pw2ZrcUueg/7BdyiqXliMGJhb0ECGLpZaCddpzUcR2fMzVVV
efrsezEhYe/B3QnMnfOaNB67CbambjHJtV161tjf6lH3kgSdI5CmGulusufyeJag
9+IoNkjiUoMuDjWiBdUlZ3FQ6/BuyJhscGSSGYwtQzYNSd+GG4MMk8z9GH+8zLw+
h1om0G8ydJwtTqBjLW/t6jRWwgz53S/We5sPLtvfw6gHTaPoLcWZRZZu1UjbMir1
1LxHPDg6a7GFyVTM2xFSV4dIE6ylgiWfrQgIIBEZUoUT4eSeEGkA5P6Ai1jrG0tB
2wTMseLdA7jhTf6s5gPHRMmWFvcNp9GN6ckEIhoF06y4dZX4fmho/M8yL/ytg8yw
bz1OsbWCKsZAPVWThLcmxN8foFo6h3Uctk0FO9PTQQ8iXgB4ZLp0qm+KRBheOhCe
NRIk/WEbEruer7NCY3I51MQj4gtVPH66PtUP13YlcK2Tk94Loes/v/egCgRxJklA
AULONp8/zi/qAyRENof0+KbpGP8lWl7uF4NN6p6qC5FHHwCGdH4iVimIWYrtW+K9
SxtgOl4CckS/P+p/bRaAaQc5EJdIGgn31olDuKUpYGV5u0q1VB+JswiCwjAGdwKB
npHHh52ftTV6yv8q03DhBzYjbADO2uhBvm0Ed+AJVJyPvUbFIWwntyaVJ18BYHLJ
zxQHnPc=
=MGvD
-----END PGP SIGNATURE-----
Merge tag 'rpmsg-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux
Pull rpmsg updates from Bjorn Andersson:
"Mark 'data' argument in rpmsg_send() const, and perculate to related
drivers. Replace deprecated class_destroy() with class_unregister()"
* tag 'rpmsg-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux:
media: platform: mtk-mdp3: Constify buffer passed to mdp_vpu_sendmsg()
ASoC: qcom: Constify GPR packet being send over GPR interface
rpmsg: Constify buffer passed to send API
remoteproc: mtk_scp: Constify buffer passed to scp_send_ipi()
remoteproc: mtk_scp_ipi: Constify buffer passed to scp_ipi_send()
drivers: rpmsg: class_destroy() is deprecated
Move requesting of IRQs in TI Keystone driver to probe time instead of
remoteproc start, to allow better handling of errors.
Introduce support for more than 10 entries in the Qualcomm minidump
implementation.
Add audio DSP remoteproc support for the Qualcomm Eliza platform. Add
modem remoteproc support for the Qualcomm MDM9607, MSM8917, MSM8937, and
MSM8940 platforms.
Add list of Qualcomm QMI service ids to the QMI header file, in order to
avoid sprinkling them across the various drivers using them. Migrate
sysmon to use this constant.
Fix several issues related to DeviceTree parsing and mailbox handling in
the Xilinx R5F remote processor driver.
Fix incorrect error checks in reserved memory handling and polish the
code across i.MX and TI drivers.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCgAsFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmnikW0OHGJqb3JuQGty
eW8uc2UACgkQCx85Pw2ZrcUa8BAAtFLoFqIOUTWLnQJkmIHB1BXlQiwDQZrA3YHU
ouoOhxJK44qInXdXfkKykJsvpO5czytG0JirpKp9XuOTOQ/D61/MzASrgp+DFrWC
dDEiCSD418n7XcZYhU/885lkgNsFwWee4KKqxv4rSIszzEjdpkCv+uuTRFFRRRUy
8GzjyEMZ5CphpC21C1S0Snbs+C8ZnNIrAeVgQmfE1BOS2PbtSP3gfEf2mxhAJiY8
H8emmY41tnmvMfW8w4H+25Q3K41UV2E6v4FwY/Cyn8RGm1wpGRGi6g6woVGuRgxi
51RafOzk7rvd41p0KwJDubjFYl2NtrZN/dA5aukbqa8oRyciACHKeuM7BfWPUAhB
ZUGB9hrnh5sFWSuFjMTqd2hQQYl6uOE9u/pZ7FmCn5Gqg6cGHKWnVD4sxE9QEVDt
ASQnBkCzedo0T/8vCVBGIKh433jXBXF+jJvifrGZQrSfbSXFHybQCMqMlyj/wjdz
+e3BHd/cmZzfCJK6QbQnisVm+VpKggCRh9d/5/RjqfVwUbHphXT6sqQsO7XuddMG
5AfJvrijrgxn9uHlEgaHLEYNox3uV1es7G7cnWoftdhFC1/8bdrnxlG/dHiSI/c6
ZcxRxuWMS1HjOKahe0xQVtrUzs2eWpde59CZQ5hTNpyuf4r7dIwxt13w7zw6pkNh
frMxDtg=
=Jqmf
-----END PGP SIGNATURE-----
Merge tag 'rproc-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux
Pull remoteproc updates from Bjorn Andersson:
- Move requesting of IRQs in TI Keystone driver to probe time instead
of remoteproc start, to allow better handling of errors.
- Introduce support for more than 10 entries in the Qualcomm minidump
implementation.
- Add audio DSP remoteproc support for the Qualcomm Eliza platform. Add
modem remoteproc support for the Qualcomm MDM9607, MSM8917, MSM8937,
and MSM8940 platforms.
- Add list of Qualcomm QMI service ids to the QMI header file, in order
to avoid sprinkling them across the various drivers using them.
Migrate sysmon to use this constant.
- Fix several issues related to DeviceTree parsing and mailbox handling
in the Xilinx R5F remote processor driver.
- Fix incorrect error checks in reserved memory handling and polish the
code across i.MX and TI drivers.
* tag 'rproc-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: (35 commits)
remoteproc: qcom: pas: Add Eliza ADSP support
dt-bindings: remoteproc: qcom,milos-pas: Document Eliza ADSP
remoteproc: qcom: Add missing space before closing bracket
dt-bindings: remoteproc: qcom: Drop types for firmware-name
remoteproc: qcom: Fix minidump out-of-bounds access on subsystems array
dt-bindings: remoteproc: k3-r5f: Add memory-region-names
dt-bindings: remoteproc: k3-r5f: Split up memory regions
remoteproc: use SIZE_MAX in rproc_u64_fit_in_size_t()
dt-bindings: remoteproc: qcom,sm8550-pas: Add Glymur CDSP
dt-bindings: remoteproc: qcom,sm8550-pas: Add Glymur ADSP
remoteproc: xlnx: Release mailbox channels on shutdown
remoteproc: sysmon: Use the unified QMI service ID instead of defining it locally
remoteproc: xlnx: Only access buffer information if IPI is buffered
remoteproc: xlnx: Avoid mailbox setup
remoteproc: keystone: Request IRQs in probe()
remoteproc: pru: Remove empty remove callback
remoteproc: pru: Use rproc_of_parse_firmware() to get firmware name
remoteproc: da8xx: Reorder resource fetching in probe()
remoteproc: da8xx: Remove unused local struct data
remoteproc: da8xx: Use dev_err_probe()
...
The ADSP found on Eliza SoC is similar to the one found on SM8550.
So just add the dedicated compatible for Eliza ADSP and reuse the
SM8550 resource configuration.
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260327-eliza-remoteproc-adsp-v1-2-1c46c5e5f809@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add missing space before closing curly bracket for qcom_q6v5_mss and
qcom_q6v5_pas driver of_match[] lines, so that all qcom remoteproc
drivers are consistent on the common coding style.
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260306145607.1394878-1-shengchao.guo@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
MAX_NUM_OF_SS was hardcoded to 10 in the minidump_global_toc struct,
which is a direct overlay on an SMEM item allocated by the firmware.
Newer Qualcomm SoC firmware allocates space for more subsystems, while
older firmware only allocates space for 10. Bumping the constant would
cause Linux to read/write beyond the SMEM item boundary on older
platforms.
Fix this by converting subsystems[] to a flexible array member and
deriving the actual number of subsystems at runtime from the size
returned by qcom_smem_get(). Add a bounds check on minidump_id against
the derived count before indexing into the array.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260331171243.1962067-1-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
scp_send_ipi() should only send the passed buffer, without modifying its
contents, so mark pointer 'buf' as pointer to const.
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260317-rpmsg-send-const-v3-2-4d7fd27f037f@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
scp_ipi_send() should only send the passed buffer, without modifying its
contents, so mark pointer 'buf' as pointer to const.
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260317-rpmsg-send-const-v3-1-4d7fd27f037f@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Smatch reports:
drivers/remoteproc/remoteproc_elf_loader.c:221
warn: always true condition '(val <= -1)'
The helper function rproc_u64_fit_in_size_t() compares the value
against (size_t)-1, which is equivalent to SIZE_MAX but can confuse
static analysis tools and lead to the above warning.
Replace (size_t)-1 with SIZE_MAX to make the intent explicit and
avoid the Smatch warning without changing the behavior.
Signed-off-by: Anas Iqbal <mohd.abd.6602@gmail.com>
Link: https://lore.kernel.org/r/20260314110137.178981-1-mohd.abd.6602@gmail.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Mailbox driver can't introduce shutdown callback, as it might endup
closing mbox channels prematurely. By allowing the client driver to
manage the shutdown process, it's ensured that mailbox channels are
closed only when they are no longer needed.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20260303235127.2317955-4-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Instead of defining a local macro with a custom name for the QMI
service identifier, use the one provided in qmi.h and remove the
locally defined macro.
Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260309230346.3584252-5-daniel.lezcano@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
In the receive callback check if message is NULL to prevent
possibility of crash by NULL pointer dereferencing.
Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Fixes: 5dfb28c257 ("remoteproc: xilinx: Add mailbox channels for rpmsg")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20260303235127.2317955-3-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Mailbox properties are optional in the remoteproc xlnx bindings.
If mailbox properties are not found in device-tree it's not fatal error
in the driver. Driver will print warning messages and continue with
normal operation. However, these warning messages can be interpreted as
error. Check "mboxes" and "mbox-names" properties in the driver and setup
mailbox only if they are available in the device-tree.
This will avoid any unwanted warning/error messages.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20260303235127.2317955-2-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
IRQs can be registered in probe and only need to be enabled/disabled
during remoteproc start/stop. This lets us catch IRQ issues early
and simplify remoteproc start/stop.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20260302201734.320747-1-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
The .remove() callback only prints out a debug message, remove
this otherwise unneeded callback.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20260302202728.322073-2-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Currently several resource are fetched before we allocate our instance
data struct. The is unlike most other drivers that fill in the instance
data with resources as they are fetched. Move these down which is more
natural and also removes the need for several temporarily locals.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20260302195616.312378-3-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
The member irq is never used and ack_fxn is unneeded as it
is already a part of another member irq_data. Drop those
and their struct docs. While touching the struct docs add
one for dsp_reset which was previously missing.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20260302195616.312378-2-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
The devm_ioremap_resource_wc() function never returns NULL, it returns
error pointers. Update the error checking to match.
Fixes: 67a7bc7f03 ("remoteproc: Use of_reserved_mem_region_* functions for "memory-region"")
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20260227092110.4044313-1-nichen@iscas.ac.cn
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
The devm_ioremap_resource_wc() function never returns NULL, it returns
error pointers. Update the error checking to match.
Fixes: 67a7bc7f03 ("remoteproc: Use of_reserved_mem_region_* functions for "memory-region"")
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20260227091546.4044246-1-nichen@iscas.ac.cn
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Add error checking for regmap_attach_dev() call in
imx_rproc_mmio_detect_mode() function to ensure proper error
propagation.
Return the value of regmap_attach_dev() if it fails to prevent
proceeding with an incomplete regmap setup.
Suggested-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Fixes: e14168bf34 ("remoteproc: imx_rproc: Simplify IMX_RPROC_MMIO switch case")
Link: https://lore.kernel.org/r/20260209051407.1467660-1-nichen@iscas.ac.cn
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Smatch reports unreachable code in imx_rproc_prepare(), where an early
return inside the reserved-memory parsing loop prevents platform
prepare_ops from being executed.
When of_reserved_mem_region_to_resource() fails, imx_rproc_prepare()
returns immediately, so the platform-specific prepare callback is never
called. As a result, prepare_ops such as imx_rproc_sm_lmm_prepare() on
i.MX95 have no chance to run.
This is problematic when Linux controls the M7 Logical Machine and is
responsible for preparing resources such as TCM. Without running the
platform prepare callback, loading the M7 ELF into TCM may fail if the
bootloader did not power up and initialize TCM.
Fix this by breaking out of the reserved-memory loop instead of
returning, allowing the platform prepare_ops to be executed as intended.
Fixes: edd2a99560 ("remoteproc: imx_rproc: Introduce prepare ops for imx_rproc_dcfg")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/linux-remoteproc/aYYXAa2Fj36XG4yQ@p14s/T/#t
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20260208-imx-rproc-fix-v1-1-ad74555eb9a4@nxp.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Prior to commit d935187cfb ("remoteproc: mediatek: Break lock
dependency to prepare_lock"), `scp->clk` was prepared and enabled only
when it needs to communicate with the SCP. The commit d935187cfb
moved the prepare operation to remoteproc's prepare(), keeping the clock
prepared as long as the SCP is running.
The power consumption due to the prolonged clock preparation can be
negligible when the system is running, as SCP is designed to be a very
power efficient processor.
However, the clock remains prepared even when the system enters system
suspend. This prevents the underlying clock controller (and potentially
the parent PLLs) from shutting down, which increases power consumption
and may block the system from entering deep sleep states.
Add suspend and resume callbacks. Unprepare the clock in suspend() if
it was active and re-prepare it in resume() to ensure the clock is
properly disabled during system suspend, while maintaining the "always
prepared" semantics while the system is active. The driver doesn't
implement .attach() callback, hence it only checks for RPROC_RUNNING.
Fixes: d935187cfb ("remoteproc: mediatek: Break lock dependency to prepare_lock")
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://lore.kernel.org/r/20260206033034.3031781-1-tzungbi@kernel.org
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
The QMI message encoder has up until recently read a single byte (as
elem_size == 1), but with the introduction of big endian support it's
become apparent that this field is expected to be a full u32 -
regardless of the size of the length in the encoded message (which is
what elem_size specifies).
The result is that the encoder now reads past the length byte and
rejects the unreasonably large length formed when including the
following 3 bytes from the subsys_name array.
Fix this by changing to the expected type.
Fixes: 1fb82ee806 ("remoteproc: qcom: Introduce sysmon")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Reviewed-by: Chris Lew <christopher.lew@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260220-qmi-encode-invalid-length-v2-1-5674be35ab29@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
As per sram bindings, "sram" property can be list of phandles.
When more than one sram phandles are listed, driver can't parse second
phandle's address correctly. Because, phandle index is passed to the API
instead of offset of address from reg property which is always 0 as per
sram.yaml bindings. Fix it by passing 0 to the API instead of sram
phandle index.
Fixes: 77fcdf51b8 ("remoteproc: xlnx: Add sram support")
Signed-off-by: Tim Michals <tcmichals@yahoo.com>
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20260204202730.3729984-1-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Add support for MSM8940 MSS it is similar for MSM8937 MSS
without inrush current mitigation.
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260107-mss-v4-9-9f4780345b6f@mainlining.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add support for MSM8937 MSS it is similar to MSM8917 MSS.
It differs primarily in that TZ needs to be informed of
the modem start address and pas_id.
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260107-mss-v4-7-9f4780345b6f@mainlining.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add support for MSM8917 MSS it is similar for MDM9607 MSS
only difference is the mss supply.
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260107-mss-v4-5-9f4780345b6f@mainlining.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add support for MDM9607 MSS it have different ACC settings
and it needs mitigation for inrush current issue.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
[Reword the commit, add necessary flags, rework inrush current mitigation]
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260107-mss-v4-3-9f4780345b6f@mainlining.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Some platforms like MSM8953 and MSM8937 TZ needs to be
informed of the modem start address and pas_id.
Lets introduce need_pas_mem_setup flag for handle this case.
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260107-mss-v4-1-9f4780345b6f@mainlining.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Commit c70b9d5fdc ("remoteproc: qcom: Use of_reserved_mem_region_*
functions for "memory-region"") switched from devm_ioremap_wc() to
devm_ioremap_resource_wc(). The difference is devm_ioremap_resource_wc()
also requests the resource which fails. Testing of both fixed and
dynamic reserved regions indicates that requesting the resource should
work, so I'm not sure why it doesn't work in this case. Fix the issue by
reverting back to devm_ioremap_wc().
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reported-by: André Apitzsch <git@apitzsch.eu>
Fixes: c70b9d5fdc ("remoteproc: qcom: Use of_reserved_mem_region_* functions for "memory-region"")
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: André Apitzsch <git@apitzsch.eu> # on BQ Aquaris M5
Link: https://lore.kernel.org/r/20260128220243.3018526-1-robh@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded
resource table even when the current firmware does not provide one.
When the device tree contains a "rsc-table" entry, priv->rsc_table is
non-NULL and denotes where a resource table would be located if one is
present in memory. However, when the current firmware has no resource
table, rproc->table_ptr is NULL. The function still returns
priv->rsc_table, and the remoteproc core interprets this as a valid loaded
resource table.
Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when
there is no resource table for the current firmware (i.e. when
rproc->table_ptr is NULL). This aligns the function's semantics with the
remoteproc core: a loaded resource table is only reported when a valid
table_ptr exists.
With this change, starting firmware without a resource table no longer
triggers a crash.
Fixes: e954a1bd16 ("remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table")
Cc: stable@vger.kernel.org
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20260129-imx-rproc-fix-v3-1-fc4e41e6e750@nxp.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
A potential circular locking dependency (ABBA deadlock) exists between
`ec_dev->lock` and the clock framework's `prepare_lock`.
The first order (A -> B) occurs when scp_ipi_send() is called while
`ec_dev->lock` is held (e.g., within cros_ec_cmd_xfer()):
1. cros_ec_cmd_xfer() acquires `ec_dev->lock` and calls scp_ipi_send().
2. scp_ipi_send() calls clk_prepare_enable(), which acquires
`prepare_lock`.
See #0 in the following example calling trace.
(Lock Order: `ec_dev->lock` -> `prepare_lock`)
The reverse order (B -> A) is more complex and has been observed
(learned) by lockdep. It involves the clock prepare operation
triggering power domain changes, which then propagates through sysfs
and power supply uevents, eventually calling back into the ChromeOS EC
driver and attempting to acquire `ec_dev->lock`:
1. Something calls clk_prepare(), which acquires `prepare_lock`. It
then triggers genpd operations like genpd_runtime_resume(), which
takes `&genpd->mlock`.
2. Power domain changes can trigger regulator changes; regulator
changes can then trigger device link changes; device link changes
can then trigger sysfs changes. Eventually, power_supply_uevent()
is called.
3. This leads to calls like cros_usbpd_charger_get_prop(), which calls
cros_ec_cmd_xfer_status(), which then attempts to acquire
`ec_dev->lock`.
See #1 ~ #6 in the following example calling trace.
(Lock Order: `prepare_lock` -> `&genpd->mlock` -> ... -> `&ec_dev->lock`)
Move the clk_prepare()/clk_unprepare() operations for `scp->clk` to the
remoteproc prepare()/unprepare() callbacks. This ensures `prepare_lock`
is only acquired in prepare()/unprepare() callbacks. Since
`ec_dev->lock` is not involved in the callbacks, the dependency loop is
broken.
This means the clock is always "prepared" when the SCP is running. The
prolonged "prepared time" for the clock should be acceptable as SCP is
designed to be a very power efficient processor. The power consumption
impact can be negligible.
A simplified calling trace reported by lockdep:
> -> #6 (&ec_dev->lock)
> cros_ec_cmd_xfer
> cros_ec_cmd_xfer_status
> cros_usbpd_charger_get_port_status
> cros_usbpd_charger_get_prop
> power_supply_get_property
> power_supply_show_property
> power_supply_uevent
> dev_uevent
> uevent_show
> dev_attr_show
> sysfs_kf_seq_show
> kernfs_seq_show
> -> #5 (kn->active#2)
> kernfs_drain
> __kernfs_remove
> kernfs_remove_by_name_ns
> sysfs_remove_file_ns
> device_del
> __device_link_del
> device_links_driver_bound
> -> #4 (device_links_lock)
> device_link_remove
> _regulator_put
> regulator_put
> -> #3 (regulator_list_mutex)
> regulator_lock_dependent
> regulator_disable
> scpsys_power_off
> _genpd_power_off
> genpd_power_off
> -> #2 (&genpd->mlock/1)
> genpd_add_subdomain
> pm_genpd_add_subdomain
> scpsys_add_subdomain
> scpsys_probe
> -> #1 (&genpd->mlock)
> genpd_runtime_resume
> __rpm_callback
> rpm_callback
> rpm_resume
> __pm_runtime_resume
> clk_core_prepare
> clk_prepare
> -> #0 (prepare_lock)
> clk_prepare
> scp_ipi_send
> scp_send_ipi
> mtk_rpmsg_send
> rpmsg_send
> cros_ec_pkt_xfer_rpmsg
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20260112110755.2435899-1-tzungbi@kernel.org
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Merge the support for loading and managing TustZone-based remote
processors found in the Qualcomm Glymur platform from a shared topic
branch, as it's a mix of qcom-soc and remoteproc patches.
Most Qualcomm platforms feature Gunyah hypervisor, which typically
handles IOMMU configuration. This includes mapping memory regions and
device memory resources for remote processors by intercepting
qcom_scm_pas_auth_and_reset() calls. These mappings are later removed
during teardown. Additionally, SHM bridge setup is required to enable
memory protection for both remoteproc metadata and its memory regions.
When the aforementioned hypervisor is absent, the operating system must
perform these configurations instead.
When Linux runs as the hypervisor (@ EL2) on a SoC, it will have its
own device tree overlay file that specifies the firmware stream ID now
managed by Linux for a particular remote processor. If the iommus
property is specified in the remoteproc device tree node, it indicates
that IOMMU configuration must be handled by Linux. In this case, the
has_iommu flag is set for the remote processor, which ensures that the
resource table, carveouts, and SHM bridge are properly configured before
memory is passed to TrustZone for authentication. Otherwise, the
has_iommu flag remains unset, which indicates default behavior.
Enables Secure PAS support for remote processors when IOMMU configuration
is managed by Linux.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-13-022e96815380@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
