summaryrefslogtreecommitdiffstats
path: root/drivers/remoteproc
AgeCommit message (Collapse)AuthorLines
2026-04-17Merge tag 'rpmsg-v7.1' of ↵Linus Torvalds-2/+2
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
2026-04-17Merge tag 'rproc-v7.1' of ↵Linus Torvalds-206/+410
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() ...
2026-04-06remoteproc: qcom: pas: Add Eliza ADSP supportAbel Vesa-0/+1
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>
2026-04-06remoteproc: qcom: Add missing space before closing bracketShawn Guo-86/+86
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>
2026-04-06remoteproc: qcom: Fix minidump out-of-bounds access on subsystems arrayMukesh Ojha-3/+14
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>
2026-04-06remoteproc: mtk_scp: Constify buffer passed to scp_send_ipi()Krzysztof Kozlowski-1/+1
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>
2026-04-06remoteproc: mtk_scp_ipi: Constify buffer passed to scp_ipi_send()Krzysztof Kozlowski-1/+1
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>
2026-03-24remoteproc: use SIZE_MAX in rproc_u64_fit_in_size_t()Anas Iqbal-1/+1
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>
2026-03-17remoteproc: xlnx: Release mailbox channels on shutdownTanmay Shah-0/+2
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>
2026-03-15remoteproc: sysmon: Use the unified QMI service ID instead of defining it ↵Daniel Lezcano-1/+1
locally 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>
2026-03-10remoteproc: xlnx: Only access buffer information if IPI is bufferedBen Levinsky-9/+11
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: 5dfb28c257b7 ("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>
2026-03-10remoteproc: xlnx: Avoid mailbox setupTanmay Shah-0/+4
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>
2026-03-09remoteproc: keystone: Request IRQs in probe()Andrew Davis-26/+15
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>
2026-03-06remoteproc: pru: Remove empty remove callbackAndrew Davis-9/+0
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>
2026-03-06remoteproc: pru: Use rproc_of_parse_firmware() to get firmware nameAndrew Davis-5/+3
There is a helper function to get the firmware name, make use of that. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20260302202728.322073-1-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-03-06remoteproc: da8xx: Reorder resource fetching in probe()Andrew Davis-43/+33
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>
2026-03-06remoteproc: da8xx: Remove unused local struct dataAndrew Davis-7/+2
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>
2026-03-06remoteproc: da8xx: Use dev_err_probe()Andrew Davis-8/+4
Simplify the probe() code by using dev_err_probe(). Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20260302195616.312378-1-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-03-05remoteproc: k3: Fix NULL vs IS_ERR() bug in k3_reserved_mem_init()Chen Ni-1/+1
The devm_ioremap_resource_wc() function never returns NULL, it returns error pointers. Update the error checking to match. Fixes: 67a7bc7f0358 ("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>
2026-03-05remoteproc: imx_rproc: Fix NULL vs IS_ERR() bug in imx_rproc_addr_init()Chen Ni-1/+1
The devm_ioremap_resource_wc() function never returns NULL, it returns error pointers. Update the error checking to match. Fixes: 67a7bc7f0358 ("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>
2026-03-05remoteproc: imx_rproc: Check return value of regmap_attach_dev() in ↵Chen Ni-1/+5
imx_rproc_mmio_detect_mode() 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: e14168bf3493 ("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>
2026-03-05remoteproc: imx_rproc: Fix unreachable platform prepare_opsPeng Fan-1/+1
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: edd2a9956055 ("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>
2026-03-05remoteproc: mediatek: Unprepare SCP clock during system suspendTzung-Bi Shih-0/+39
Prior to commit d935187cfb27 ("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 d935187cfb27 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: d935187cfb27 ("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>
2026-03-04remoteproc: sysmon: Correct subsys_name_len type in QMI requestBjorn Andersson-1/+1
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: 1fb82ee806d1 ("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>
2026-02-24remoteproc: xlnx: Fix sram property parsingTim Michals-1/+1
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: 77fcdf51b8ca ("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>
2026-02-23remoteproc: qcom_q6v5_mss: Add MSM8940Barnabás Czémán-2/+51
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>
2026-02-23remoteproc: qcom_q6v5_mss: Add MSM8937Barnabás Czémán-2/+51
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>
2026-02-23remoteproc: qcom_q6v5_mss: Add MSM8917Barnabás Czémán-2/+51
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>
2026-02-23remoteproc: qcom_q6v5_mss: Add MDM9607Stephan Gerhold-6/+66
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>
2026-02-23remoteproc: qcom_q6v5_mss: Introduce need_pas_mem_setupBarnabás Czémán-1/+15
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>
2026-02-23remoteproc: qcom_wcnss: Fix reserved region mapping failureRob Herring (Arm)-1/+1
Commit c70b9d5fdcd7 ("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: c70b9d5fdcd7 ("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>
2026-02-21Convert 'alloc_obj' family to use the new default GFP_KERNEL argumentLinus Torvalds-17/+17
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>
2026-02-21treewide: Replace kmalloc with kmalloc_obj for non-scalar typesKees Cook-18/+17
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>
2026-02-03remoteproc: imx_rproc: Fix invalid loaded resource table detectionPeng Fan-0/+4
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: e954a1bd1610 ("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>
2026-01-26remoteproc: mediatek: Break lock dependency to `prepare_lock`Tzung-Bi Shih-13/+30
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>
2026-01-13Merge branch '20260105-kvmrprocv10-v10-0-022e96815380@oss.qualcomm.com' of ↵Bjorn Andersson-35/+130
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into rproc-next 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.
2026-01-13remoteproc: qcom: pas: Enable Secure PAS support with IOMMU managed by LinuxMukesh Ojha-5/+43
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>
2026-01-13remoteproc: pas: Extend parse_fw callback to fetch resources via SMC callMukesh Ojha-2/+57
Qualcomm remote processor may rely on static and dynamic resources for it to be functional. For most of the Qualcomm SoCs, when run with Gunyah or older QHEE hypervisor, all the resources whether it is static or dynamic, is managed by the hypervisor. Dynamic resources if it is present for a remote processor will always be coming from secure world via SMC call while static resources may be present in remote processor firmware binary or it may be coming from SMC call along with dynamic resources. Remoteproc already has method like rproc_elf_load_rsc_table() to check firmware binary has resources or not and if it is not having then we pass NULL and zero as input resource table and its size argument respectively to qcom_scm_pas_get_rsc_table() and while it has resource present then it should pass the present resources to Trustzone(TZ) so that it could authenticate the present resources and append dynamic resource to return in output_rt argument along with authenticated resources. Extend parse_fw callback to include SMC call to get resources from Trustzone and to leverage resource table parsing and mapping and unmapping code from the remoteproc framework. 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/20260105-kvmrprocv10-v10-12-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-13soc: qcom: mdtloader: Add PAS context aware qcom_mdt_pas_load() functionMukesh Ojha-19/+5
Introduce a new PAS context-aware function, qcom_mdt_pas_load(), for remote processor drivers. This function utilizes the PAS context pointer returned from qcom_scm_pas_ctx_init() to perform firmware metadata verification and memory setup via SMC calls. The qcom_mdt_pas_load() and qcom_mdt_load() functions are largely similar, but the former is designed for clients using the PAS context-based data structure. Over time, all users of qcom_mdt_load() can be migrated to use qcom_mdt_pas_load() for consistency and improved abstraction. As the remoteproc PAS driver (qcom_q6v5_pas) has already adopted the PAS context-based approach, update it to use qcom_mdt_pas_load(). 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/20260105-kvmrprocv10-v10-6-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-13remoteproc: pas: Replace metadata context with PAS context structureMukesh Ojha-11/+27
As a superset of the existing metadata context, the PAS context structure enables both remoteproc and non-remoteproc subsystems to better support scenarios where the SoC runs with or without the Gunyah hypervisor. To reflect this, relevant SCM and metadata functions are updated to incorporate PAS context awareness and remove metadata context data structure completely. Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-5-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-13remoteproc: imx_rproc: Add support for i.MX95Peng Fan-0/+22
Add imx_rproc_cfg_imx95_m7 and address(TCM and DDR) mapping. Add i.MX95 of_device_id entry. Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20260109-imx95-rproc-2026-1-8-v6-6-d2fefb36263d@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-13remoteproc: imx_rproc: Add support for System Manager CPU APIPeng Fan-2/+33
When the System Manager configuration places the M7 core in the same Logical Machine(LM) as the A55 cores (M7 LM ID equals A55 LM ID), Linux can control M7 using the CPU protocol API. For more details, see the previous patch that adds LMM API support. Changes include: - Introduce imx_rproc_ops_sm_cpu for CPU API operations. - Reuse imx_rproc_sm_detect_mode to detect shared LM and set priv->ops to imx_rproc_ops_sm_cpu. - Implement imx_rproc_sm_cpu_{start,stop} to handle M7 start and stop. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20260109-imx95-rproc-2026-1-8-v6-5-d2fefb36263d@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-13remoteproc: imx_rproc: Add support for System Manager LMM APIPeng Fan-0/+171
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 <daniel.baluta@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20260109-imx95-rproc-2026-1-8-v6-4-d2fefb36263d@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-13remoteproc: imx_rproc: Introduce prepare ops for imx_rproc_dcfgPeng Fan-0/+6
Allow each platform to provide its own prepare operations, preparing for i.MX95 LMM and CPU ops support. No functional changes. Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20260109-imx95-rproc-2026-1-8-v6-3-d2fefb36263d@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-13remoteproc: imx_rproc: Add runtime ops copy to support dynamic behaviorPeng Fan-14/+13
Structure imx_rproc_dcfg contains a const pointer to imx_rproc_plat_ops, which defines the start/stop/detect_mode operations for a remote processor. To preserve the const correctness of the static configuration while allowing runtime modification of ops behavior, introduce a new imx_rproc_plat_ops member in struct imx_rproc named `ops`. During initialization, dcfg->ops is assigned to priv->ops. Enable the driver to safely override ops at runtime without affecting the original const configuration. Improve flexibility for platforms that require dynamic operation switching (e.g. i.MX95 Logical Machine ops and CPU ops). Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20260109-imx95-rproc-2026-1-8-v6-2-d2fefb36263d@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-05remoteproc: xlnx_r5: Simplify with scoped for each OF child loopKrzysztof Kozlowski-7/+2
Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260102124827.64355-4-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-05remoteproc: mtk_scp: Simplify with scoped for each OF child loopKrzysztof Kozlowski-6/+1
Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260102124827.64355-3-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-01-05remoteproc: imx_dsp_rproc: Only reset carveout memory at RPROC_OFFLINE stateShengjiu Wang-3/+5
Do not reset memory at suspend and resume stage, because some memory is used to save the software state for resume, if it is cleared, the resume operation can fail. Fixes: c4c432dfb00f ("remoteproc: imx_dsp_rproc: Add support of recovery and coredump process") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Link: https://lore.kernel.org/r/20251218071750.2692132-1-shengjiu.wang@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-12-17remoteproc: imx_dsp_rproc: Fix multiple start/stop operationsDaniel Baluta-17/+33
After commit 67a7bc7f0358 ("remoteproc: Use of reserved_mem_region_* functions for "memory-region"") following commands with imx-dsp-rproc started to fail: $ echo zephyr.elf > /sys/class/remoteproc/remoteproc0/firmware $ echo start > /sys/class/remoteproc/remoteproc0/state $ echo stop > /sys/class/remoteproc/remoteproc0/state $ echo start > /sys/class/remoteproc/remoteproc0/state #! This fails -sh: echo: write error: Device or resource busy This happens because aforementioned commit replaced devm_ioremap_wc with devm_ioremap_resource_wc which will "reserve" the memory region with the first start and then will fail at the second start if the memory region is already reserved. Even partially reverting the faulty commit won't fix the underlying issue because we map the address in prepare() but we never unmap it at unprepare(), so we will keep leaking memory regions. So, lets use alloc() and release() callbacks for memory carveout handling. This will nicely map() the memory region at prepare() time and unmap() it at unprepare(). Fixes: 67a7bc7f0358 ("remoteproc: Use of_reserved_mem_region_* functions for "memory-region"") Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20251210154906.99210-1-daniel.baluta@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-12-16remoteproc: imx_rproc: Use strstarts for "rsc-table" checkShenwei Wang-1/+1
The resource name may include an address suffix, for example: rsc-table@1fff8000. To handle such cases, use strstarts() instead of strcmp() when checking for "rsc-table". Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Fixes: 67a7bc7f0358 ("remoteproc: Use of_reserved_mem_region_* functions for "memory-region"") Link: https://lore.kernel.org/r/20251208233302.684139-1-shenwei.wang@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>