kernel/git/next/linux-next.git/drivers/remoteproc/Kconfig, branch master

remoteproc: Add compile testing for additional TI drivers

2026-09-15T15:41:55+00:00

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 Reviewed-by: Beleswar Padhi Tested-by: Beleswar Padhi Link: https://lore.kernel.org/r/20260904195634.2275867-3-afd@ti.com Signed-off-by: Mathieu Poirier

remoteproc: Add AMD MicroBlaze/V BRAM-based remote processor driver

2026-07-20T17:15:43+00:00

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 Link: https://lore.kernel.org/r/20260714202441.554065-3-ben.levinsky@amd.com Signed-off-by: Mathieu Poirier

remoteproc: qcom: Select QCOM_PAS generic service

2026-07-09T19:21:57+00:00

Select PAS generic service driver to enable support for multiple PAS backends like OP-TEE in addition to SCM. Tested-by: Mukesh Ojha # Lemans Tested-by: Vignesh Viswanathan # IPQ9650 Signed-off-by: Sumit Garg Link: https://lore.kernel.org/r/20260702115835.167602-8-sumit.garg@kernel.org Signed-off-by: Bjorn Andersson

remoteproc: qcom: Unify user-visible "Qualcomm" name

2026-06-09T02:49:48+00:00

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 Link: https://lore.kernel.org/r/20260422083334.84294-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson

remoteproc: Dead code cleanup in Kconfig for STM32_RPROC

2026-04-27T17:21:32+00:00

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 Acked-by: Arnaud Pouliquen Link: https://lore.kernel.org/r/20260417221337.286313-1-julianbraha@gmail.com Signed-off-by: Mathieu Poirier

remoteproc: imx_rproc: Add support for System Manager LMM API

2026-01-13T16:52:35+00:00

i.MX95 features a Cortex-M33 core, six Cortex-A55 cores, and one Cortex-M7 core. The System Control Management Interface(SCMI) firmware runs on the M33 core. The i.MX95 SCMI firmware named System Manager(SM) includes vendor extension protocols, Logical Machine Management(LMM) protocol and CPU protocol and etc. Depending on SM configuration, M7 can be used as follows: (1) M7 in a separate Logical Machine (LM) from A55 cores, that Linux can't control (2) M7 in a separate LM from A55 cores that Linux can control using LMM protocol. (3) M7 runs in same Logical Machine as A55 cores, so Linux can control it using CPU protocol So extend the driver to using LMM and CPU protocol to manage the M7 core. - Compare linux LM ID(got using scmi_imx_lmm_info) and M7 LM ID(the ID is fixed as 1 in SM firmware if M7 is in a separate LM), if Linux LM ID is not same as M7 LM ID(linux and M7 in same LM), use LMM protocol to start/stop. CPU protocol support will be added in the following patch. Whether using CPU or LMM protocol to start/stop, the M7 status detection could use CPU protocol to detect started or not. So in imx_rproc_detect_mode, use scmi_imx_cpu_started to check the status of M7. - For above case (1) and (2), Use SCMI_IMX_LMM_POWER_ON to detect whether the M7 LM is under control of A55 LM. - For above case , after using SCMI_IMX_LMM_POWER_ON to check permission, SCMI_IMX_LMM_SHUTDOWN API should be called to shutdown the M7 LM to save power only when M7 LM is going to be started by remoteproc framework. Otherwise bypass SCMI_IMX_LMM_SHUTDOWN API if M7 LM is started before booting Linux. Current setup relies on pre-Linux software(U-Boot) to do M7 TCM ECC initialization. In future, we could add the support in Linux to decouple U-Boot and Linux. Reviewed-by: Daniel Baluta Reviewed-by: Frank Li Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20260109-imx95-rproc-2026-1-8-v6-4-d2fefb36263d@nxp.com Signed-off-by: Mathieu Poirier

remoteproc: qcom: pas: Conclude the rename from adsp

2025-06-11T03:03:47+00:00

The change that renamed the driver from "adsp" to "pas" didn't change any of the implementation. The result is an aesthetic eyesore, and confusing to many. Conclude the rename of the driver, by updating function, structures and variable names to match what the driver actually is. The "Hexagon v5" is also dropped from the name and Kconfig, as this isn't correct either. No functional change. Fixes: 9e004f97161d ("remoteproc: qcom: Rename Hexagon v5 PAS driver") Signed-off-by: Bjorn Andersson Reviewed-by: Wasim Nazir Link: https://lore.kernel.org/r/20250605-pas-rename-v2-1-f1c89e49e691@oss.qualcomm.com Signed-off-by: Bjorn Andersson

remoteproc: k3-r5: Add compile testing support

2024-10-18T15:59:21+00:00

This driver can be compile tested on non-K3 architectures as long as TI_SCI_PROTOCOL is not compiled as a module. Enable this here to improve this driver's build coverage. Signed-off-by: Andrew Davis Link: https://lore.kernel.org/r/20241016164141.93401-3-afd@ti.com Signed-off-by: Mathieu Poirier

remoteproc: k3-dsp: Add compile testing support

2024-10-18T15:59:21+00:00

mailbox, remoteproc: k3-m4+: fix compile testing

2024-10-16T15:49:24+00:00

The k3-m4 remoteproc driver was merged with incorrect dependencies. Despite multiple people trying to fix this, the version 6.12-rc2 remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m when the driver is built-in. arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function `k3_m4_rproc_probe': ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to `devm_ti_sci_get_by_phandle' Fix the dependency again to make it work in all configurations. The 'select OMAP2PLUS_MBOX' no longer matches what the other drivers dependencies. The link failure can be avoided with a simple 'depends do, so turn that into the same 'depends' to ensure we get no circular on TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is what we use elsehwere. On the other hand, building for OMAP2PLUS makes no sense since the hardware only exists on K3. Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem") Fixes: ba0c0cb56f22 ("remoteproc: k3-m4: use the proper dependencies") Fixes: 54595f2807d2 ("mailbox, remoteproc: omap2+: fix compile testing") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20241007132441.2732215-1-arnd@kernel.org Signed-off-by: Mathieu Poirier