Changes in Kconfig

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

Wed, 22 Apr 2026 10:33:35 +0200

remoteproc: qcom: Unify user-visible "Qualcomm" nameVarious names for Qualcomm as a company are used in user-visible configoptions: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified"Qualcomm" so it will be easier for users to identify the options whenfor example running menuconfig.Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20260422083334.84294-2-krzysztof.kozlowski@oss.qualcomm.comSigned-off-by: Bjorn Andersson List of files: /linux/drivers/remoteproc/Kconfig

f9915120d004a8e9e64afee138dd448cd7cad9bc - remoteproc: Dead code cleanup in Kconfig for STM32_RPROC

Sat, 18 Apr 2026 00:13:37 +0200

remoteproc: Dead code cleanup in Kconfig for STM32_RPROCThere 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 theindividual '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.comSigned-off-by: Mathieu Poirier List of files: /linux/drivers/remoteproc/Kconfig

d8ab94fa4370337158e96ea08d41e6e2d8fcb2a2 - remoteproc: imx_rproc: Add support for System Manager LMM API

Fri, 09 Jan 2026 13:08:04 +0100

remoteproc: imx_rproc: Add support for System Manager LMM APIi.MX95 features a Cortex-M33 core, six Cortex-A55 cores, andone Cortex-M7 core. The System Control Management Interface(SCMI)firmware runs on the M33 core. The i.MX95 SCMI firmware named SystemManager(SM) includes vendor extension protocols, Logical MachineManagement(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 protocolSo 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 ECCinitialization. In future, we could add the support in Linux to decoupleU-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.comSigned-off-by: Mathieu Poirier List of files: /linux/drivers/remoteproc/Kconfig

2c0c883f895f16fd9d367ec2e64bccab907d8d87 - remoteproc: qcom: pas: Conclude the rename from adsp

Fri, 06 Jun 2025 00:17:47 +0200

remoteproc: qcom: pas: Conclude the rename from adspThe change that renamed the driver from "adsp" to "pas" didn't changeany of the implementation. The result is an aesthetic eyesore, andconfusing to many.Conclude the rename of the driver, by updating function, structures andvariable names to match what the driver actually is. The "Hexagon v5" isalso 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.comSigned-off-by: Bjorn Andersson List of files: /linux/drivers/remoteproc/Kconfig

be3e6529a8b90b1284a55117a4e23095ccbeaeaf - remoteproc: k3-r5: Add compile testing support

Wed, 16 Oct 2024 18:41:41 +0200

remoteproc: k3-r5: Add compile testing supportThis driver can be compile tested on non-K3 architectures as longas TI_SCI_PROTOCOL is not compiled as a module. Enable this hereto improve this driver's build coverage.Signed-off-by: Andrew Davis Link: https://lore.kernel.org/r/20241016164141.93401-3-afd@ti.comSigned-off-by: Mathieu Poirier List of files: /linux/drivers/remoteproc/Kconfig

0db357ef93281606936459de6fd9ee7cd2c14593 - remoteproc: k3-dsp: Add compile testing support

Wed, 16 Oct 2024 18:41:40 +0200

remoteproc: k3-dsp: Add compile testing supportThis driver can be compile tested on non-K3 architectures as longas TI_SCI_PROTOCOL is not compiled as a module. Enable this hereto improve this driver's build coverage.Signed-off-by: Andrew Davis Link: https://lore.kernel.org/r/20241016164141.93401-2-afd@ti.comSigned-off-by: Mathieu Poirier List of files: /linux/drivers/remoteproc/Kconfig

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

Mon, 07 Oct 2024 15:23:57 +0200

mailbox, remoteproc: k3-m4+: fix compile testingThe k3-m4 remoteproc driver was merged with incorrect dependencies.Despite multiple people trying to fix this, the version 6.12-rc2remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=mwhen 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 driversdependencies. The link failure can be avoided with a simple 'dependsdo, so turn that into the same 'depends' to ensure we get no circularon TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is whatwe use elsehwere. On the other hand, building for OMAP2PLUS makesno 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.orgSigned-off-by: Mathieu Poirier List of files: /linux/drivers/remoteproc/Kconfig

e7ed343658792771cf1b868df061661b7bcc5cef - Merge tag 'mailbox-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox

Sun, 29 Sep 2024 18:53:04 +0200

Merge tag 'mailbox-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailboxPull mailbox updates from Jassi Brar: - fix kconfig dependencies (mhu-v3, omap2+) - use devie name instead of genereic imx_mu_chan as interrupt name (imx) - enable sa8255p and qcs8300 ipc controllers (qcom) - Fix timeout during suspend mode (bcm2835) - convert to use use of_property_match_string (mailbox) - enable mt8188 (mediatek) - use devm_clk_get_enabled helpers (spreadtrum) - fix device-id typo (rockchip)* tag 'mailbox-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox: mailbox, remoteproc: omap2+: fix compile testing dt-bindings: mailbox: qcom-ipcc: Document QCS8300 IPCC dt-bindings: mailbox: qcom-ipcc: document the support for SA8255p dt-bindings: mailbox: mtk,adsp-mbox: Add compatible for MT8188 mailbox: Use of_property_match_string() instead of open-coding mailbox: bcm2835: Fix timeout during suspend mode mailbox: sprd: Use devm_clk_get_enabled() helpers mailbox: rockchip: fix a typo in module autoloading mailbox: imx: use device name in interrupt name mailbox: ARM_MHU_V3 should depend on ARM64 List of files: /linux/drivers/remoteproc/Kconfig

54595f2807d203770ee50486cb23dc5763916d72 - mailbox, remoteproc: omap2+: fix compile testing

Mon, 09 Sep 2024 22:38:09 +0200

mailbox, remoteproc: omap2+: fix compile testingSelecting CONFIG_OMAP2PLUS_MBOX while compile testingcauses a build failure:WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX Depends on [n]: MAILBOX [=y] && (ARCH_OMAP2PLUS || ARCH_K3) Selected by [m]: - TI_K3_M4_REMOTEPROC [=m] && REMOTEPROC [=y] && (ARCH_K3 || COMPILE_TEST [=y])Using 'select' to force-enable another subsystem is generallya mistake and causes problems such as this one, so change thethree drivers that link against this driver to use 'depends on'instead, and ensure the driver itself can be compile testedregardless of the platform.When compile-testing without CONFIG_TI_SCI_PROTOCOL=m, thereis a chance for a link failure, so add a careful dependencyon that.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'Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem")Signed-off-by: Arnd Bergmann Reviewed-by: Mathieu Poirier Reviewed-by: Andrew Davis Reviewed-by: Martyn Welch Signed-off-by: Jassi Brar List of files: /linux/drivers/remoteproc/Kconfig

ba0c0cb56f227d9af9c19a276fac982c492c079f - remoteproc: k3-m4: use the proper dependencies

Tue, 24 Sep 2024 21:48:35 +0200

remoteproc: k3-m4: use the proper dependenciesThe TI_K3_M4_REMOTEPROC Kconfig entry selects OMAP2PLUS_MBOX, but thatdriver in turn depends on other things, which the k4-m4 driver didn't.This causes a Kconfig time warning: WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX Depends on [n]: MAILBOX [=y] && (ARCH_OMAP2PLUS || ARCH_K3) Selected by [m]: - TI_K3_M4_REMOTEPROC [=m] && REMOTEPROC [=y] && (ARCH_K3 || COMPILE_TEST [=y])because you can't select something that is unavailable.Make the dependencies for TI_K3_M4_REMOTEPROC match those of theOMAP2PLUS_MBOX driver that it needs.Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem")Cc: Bjorn Andersson Cc: Martyn Welch Cc: Hari Nagalla Cc: Andrew Davis Cc: Mathieu Poirier Signed-off-by: Linus Torvalds List of files: /linux/drivers/remoteproc/Kconfig

ebcf9008a895a2a9416f69e186b56fbade35e12c - remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

Fri, 02 Aug 2024 17:21:03 +0200

remoteproc: k3-m4: Add a remoteproc driver for M4F subsystemThe AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core inthe MCU domain. This core is typically used for safety applications in astand alone mode. However, some application (non safety related) maywant to use the M4F core as a generic remote processor with IPC to thehost processor. The M4F core has internal IRAM and DRAM memories and areexposed to the system bus for code and data loading.A remote processor driver is added to support this subsystem, includingbeing able to load and boot the M4F core. Loading includes to M4Finternal memories and predefined external code/data memories. Thecarve outs for external contiguous memory is defined in the M4F devicenode and should match with the external memory declarations in the M4Fimage binary. The M4F subsystem has two resets. One reset is for theentire subsystem i.e including the internal memories and the other, alocal reset is only for the M4F processing core. When loading the image,the driver first releases the subsystem reset, loads the firmware imageand then releases the local reset to let the M4F processing core run.Signed-off-by: Martyn Welch Signed-off-by: Hari Nagalla Signed-off-by: Andrew Davis Tested-by: Wadim Egorov Link: https://lore.kernel.org/r/20240802152109.137243-4-afd@ti.comSigned-off-by: Mathieu Poirier List of files: /linux/drivers/remoteproc/Kconfig

e9b854382c8df07385c778bd8b25c03442bfa9e2 - remoteproc: qcom: select AUXILIARY_BUS

Wed, 26 Jun 2024 21:12:38 +0200

remoteproc: qcom: select AUXILIARY_BUSThe QCOM_PD_MAPPER implementation made Qualcomm remoteproc drivers useauxiliary bus for the pd-mapper subdevice. Add necessary dependency.Reported-by: Mark Brown Fixes: 5b9f51b200dc ("remoteproc: qcom: enable in-kernel PD mapper")Signed-off-by: Dmitry Baryshkov Reviewed-by: Chris Lew Link: https://lore.kernel.org/r/20240626-qcom-pd-mapper-fix-deps-v1-2-644678dc4663@linaro.orgSigned-off-by: Bjorn Andersson List of files: /linux/drivers/remoteproc/Kconfig

03bd158e1535e68bcd2b1e095b0ebcad7c84bd20 - remoteproc: stm32: use correct format strings on 64-bit

Fri, 09 Jun 2023 12:45:42 +0200

remoteproc: stm32: use correct format strings on 64-bitWith CONFIG_ARCH_STM32 making it into arch/arm64, a couple of formatstrings no longer work, since they rely on size_t being compatiblewith %x, or they print an 'int' using %z:drivers/remoteproc/stm32_rproc.c: In function 'stm32_rproc_mem_alloc':drivers/remoteproc/stm32_rproc.c:122:22: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'size_t' {aka 'long unsigned int'} [-Werror=format=]drivers/remoteproc/stm32_rproc.c:122:40: note: format string is defined here 122 | dev_dbg(dev, "map memory: %pa+%x\n", &mem->dma, mem->len); | ~^ | | | unsigned int | %lxdrivers/remoteproc/stm32_rproc.c:125:30: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'size_t' {aka 'long unsigned int'} [-Werror=format=]drivers/remoteproc/stm32_rproc.c:125:65: note: format string is defined here 125 | dev_err(dev, "Unable to map memory region: %pa+%x\n", | ~^ | | | unsigned int | %lxdrivers/remoteproc/stm32_rproc.c: In function 'stm32_rproc_get_loaded_rsc_table':drivers/remoteproc/stm32_rproc.c:646:30: error: format '%zx' expects argument of type 'size_t', but argument 4 has type 'int' [-Werror=format=]drivers/remoteproc/stm32_rproc.c:646:66: note: format string is defined here 646 | dev_err(dev, "Unable to map memory region: %pa+%zx\n", | ~~^ | | | long unsigned int | %xFix up all three instances to work across architectures, and enablecompile testing for this driver to ensure it builds everywhere.Reviewed-by: Arnaud Pouliquen Acked-by: Randy Dunlap Tested-by: Randy Dunlap Signed-off-by: Arnd Bergmann List of files: /linux/drivers/remoteproc/Kconfig

6b291e8020a8bd90e94ee13d61f251040425c90d - drivers: remoteproc: Add Xilinx r5 remoteproc driver

Tue, 15 Nov 2022 00:39:40 +0100

drivers: remoteproc: Add Xilinx r5 remoteproc driverThis driver enables r5f dual core Real time Processing Unit subsystemavailable on Xilinx Zynq Ultrascale MPSoC Platform. RPU subsystem(cluster) can be configured in different modes e.g. split mode in whichtwo r5f cores work independent of each other and lock-step mode in whichboth r5f cores execute same code clock-for-clock and notify if theresult is different.The Xilinx r5 Remoteproc Driver boots the RPU cores via calls to the XilinxPlatform Management Unit that handles the R5 configuration, memory accessand R5 lifecycle management. The interface to this manager is done in thisdriver via zynqmp_pm_* function calls.Signed-off-by: Ben Levinsky Signed-off-by: Tanmay Shah Reported-by: kernel test robot Link: https://lore.kernel.org/r/20221114233940.2096237-7-tanmay.shah@amd.comSigned-off-by: Mathieu Poirier List of files: /linux/drivers/remoteproc/Kconfig

eee412e968f7b950564880bc6a7a9f00f49034da - remoteproc: qcom: q6v5: fix service routines build errors

Sat, 15 Jan 2022 02:13:38 +0100

remoteproc: qcom: q6v5: fix service routines build errorsWhen CONFIG_QCOM_AOSS_QMP=m and CONFIG_QCOM_Q6V5_MSS=y, the builtindriver cannot call into the loadable module's low-level servicefunctions. Trying to build with that config combo causes linker errors.There are two problems here. First, drivers/remoteproc/qcom_q6v5.cshould #include for the definitions ofthe service functions, depending on whether CONFIG_QCOM_AOSS_QMP isset/enabled or not. Second, the qcom remoteproc drivers should dependon QCOM_AOSS_QMP iff it is enabled (=y or =m) so that the qcomremoteproc drivers can be built properly.This prevents these build errors:aarch64-linux-ld: drivers/remoteproc/qcom_q6v5.o: in function `q6v5_load_state_toggle':qcom_q6v5.c:(.text+0xc4): undefined reference to `qmp_send'aarch64-linux-ld: drivers/remoteproc/qcom_q6v5.o: in function `qcom_q6v5_deinit':(.text+0x2e4): undefined reference to `qmp_put'aarch64-linux-ld: drivers/remoteproc/qcom_q6v5.o: in function `qcom_q6v5_init':(.text+0x778): undefined reference to `qmp_get'aarch64-linux-ld: (.text+0x7d8): undefined reference to `qmp_put'Fixes: c1fe10d238c0 ("remoteproc: qcom: q6v5: Use qmp_send to update co-processor load state")Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Bjorn Andersson Cc: Mathieu Poirier Cc: linux-remoteproc@vger.kernel.orgCc: Sibi Sankar Cc: Stephen Boyd Reviewed-by: Stephen Boyd Reviewed-by: Bjorn Andersson Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220115011338.2973-1-rdunlap@infradead.org List of files: /linux/drivers/remoteproc/Kconfig

285892a74f1370a12249f765c6a4e3b16194852e - remoteproc: Add Renesas rcar driver

Tue, 07 Dec 2021 17:58:29 +0100

remoteproc: Add Renesas rcar driverRenesas Gen3 platform includes a Cortex-r7 processor.Both: the application cores (A5x) and the realtime core (CR7)share access to the RAM and devices with the same address map,so device addresses are equal to the Linux physical addresses.In order to initialize this remote processor we need to:- power on the realtime core- put the firmware in a RAM area- set the boot address for this firmware (reset vector)- Deassert the resetThis initial driver allows to start and stop the Cortex R7processor.Signed-off-by: Julien Massot Link: https://lore.kernel.org/r/20211207165829.195537-3-julien.massot@iot.bzhSigned-off-by: Mathieu Poirier List of files: /linux/drivers/remoteproc/Kconfig

ec0e5549f3586d2cb99a05edd006d722ebad912c - remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MX

Mon, 11 Oct 2021 11:20:14 +0200

remoteproc: imx_dsp_rproc: Add remoteproc driver for DSP on i.MXProvide a basic driver to control DSP processor found on NXP i.MX8QM,i.MX8QXP, i.MX8MP and i.MX8ULP.Currently it is able to resolve addresses between DSP and main CPU,start and stop the processor, suspend and resume.The communication between DSP and main CPU is based on mailbox, thereare three mailbox channels (tx, rx, rxdb).This driver was tested on NXP i.MX8QM, i.MX8QXP, i.MX8MP and i.MX8ULP.Signed-off-by: Shengjiu Wang Link: https://lore.kernel.org/r/1633944015-789-4-git-send-email-shengjiu.wang@nxp.comSigned-off-by: Mathieu Poirier List of files: /linux/drivers/remoteproc/Kconfig

6cb58ea897dd1d10b1a52c16b344f112102cf7d3 - remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesor

Tue, 21 Sep 2021 21:25:57 +0200

remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesorAmlogic Meson6, Meson8, Meson8b and Meson8m2 embed an ARC core in theAlways-On (AO) power-domain. This is typically used for waking up theARM cores after system suspend.The configuration is spread across three different registers:- AO_REMAP_REG0 which must be programmed to zero, it's actual purpose is unknown. There is a second remap register which is not used in the vendor kernel (which served as reference for this driver).- AO_CPU_CNTL is used to start and stop the ARC core.- AO_SECURE_REG0 in the SECBUS2 register area with unknown purpose.To boot the ARC core we also need to enable it's gate clock and triggera reset.The actual code for this ARC core can come from an ELF binary, forexample by building the Zephyr RTOS for an ARC EM4 core and then taking"zephyr.elf" as firmware. This executable does not have any "rsc table"so we are skipping rproc_elf_load_rsc_table (rproc_ops.parse_fw) andrproc_elf_find_loaded_rsc_table (rproc_ops.find_loaded_rsc_table).Signed-off-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20210921192557.1610709-3-martin.blumenstingl@googlemail.com[Fixed header file order]Signed-off-by: Mathieu Poirier Signed-off-by: Bjorn Andersson List of files: /linux/drivers/remoteproc/Kconfig

fc1b6b6439588329ca3de77ca0c68c1b5bc3c7d0 - remoteproc: qcom: Loosen dependency on RPMSG_QCOM_SMD

Tue, 24 Aug 2021 01:51:20 +0200

remoteproc: qcom: Loosen dependency on RPMSG_QCOM_SMDThere doesn't seem to be any actual build time dependency on theRPMSG_QCOM_SMD, besides that these drivers should be a module if the smdrpmsg code is a module. Drop the compile test dependency so that thesedrivers can be used without RPMSG_QCOM_SMD being enabled. This is usefulfor the qcom SoCs that are using RPMSG_QCOM_GLINK_SMEM instead ofRPMSG_QCOM_SMD and thus don't want to enable the SMD driver when it isnever used.Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20210823235120.1203512-2-swboyd@chromium.orgSigned-off-by: Bjorn Andersson List of files: /linux/drivers/remoteproc/Kconfig

1cd6239426a47efb8eab6cdcb1e45ffd5601b12e - remoteproc: imx-rproc: Fix IMX_REMOTEPROC configuration

Thu, 10 Jun 2021 05:15:30 +0200

remoteproc: imx-rproc: Fix IMX_REMOTEPROC configurationWhen CONFIG_IMX_REMOTEPROC is y and CONFIG_HAVE_ARM_SMCCCis not set, compiling errors are encountered as follows:drivers/remoteproc/imx_rproc.o: in function `imx_rproc_stop':imx_rproc.c:(.text+0x140): undefined reference to `__arm_smccc_smc'drivers/remoteproc/imx_rproc.o: in function `imx_rproc_detect_mode':imx_rproc.c:(.text+0x272): undefined reference to `__arm_smccc_smc'drivers/remoteproc/imx_rproc.o: in function `imx_rproc_start':imx_rproc.c:(.text+0x5e0): undefined reference to `__arm_smccc_smc'__arm_smccc_smc is defined when HAVE_ARM_SMCCC is y, soadd dependency on HAVE_ARM_SMCCC in IMX_REMOTEPROC configuration.Fixes: 79806d32d5aa ("remoteproc: imx_rproc: support i.MX8MN/P")Reviewed-by: Mathieu Poirier Reported-by: kernel test robot Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20210610031530.26326-1-peng.fan@oss.nxp.comSigned-off-by: Bjorn Andersson List of files: /linux/drivers/remoteproc/Kconfig