Re: [PATCH 7/8] soc: qcom: mdt_loader: remove qcom_mdt_load()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mm: devres memory leak in device lifecycle functions due to devm_qcom_pas_context_alloc()
--

commit 7aed1d3e9c7b0aae366ecbadb5ead9994e82f517
Author: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>

soc: qcom: mdt_loader: remove qcom_mdt_load()

This commit removes the qcom_mdt_load() wrapper since all callers have been
migrated to qcom_mdt_pas_load(). The new function takes an explicit
qcom_pas_context and delegates memory setup to it.

> All callers have been migrated to qcom_mdt_pas_load(), which takes an
> explicit qcom_pas_context instead of a raw pas_id and delegates memory
> setup to the context.

[Severity: Medium]
Does this migration introduce a memory leak of struct qcom_pas_context?

The migration to qcom_mdt_pas_load() requires an explicit context allocated
via devm_qcom_pas_context_alloc(). This allocation is now placed inside
functions like ath12k_ahb_power_up(), venus_load_fw(), and
iris_load_fw_to_memory():

drivers/net/wireless/ath/ath12k/ahb.c:ath12k_ahb_power_up() {
    ...
    ctx = devm_qcom_pas_context_alloc(dev, pasid, rproc_info->mem_phys,
                                      rproc_info->mem_size);
    ...
}

drivers/media/platform/qcom/venus/firmware.c:venus_load_fw() {
    ...
    core->fw.pas_ctx = devm_qcom_pas_context_alloc(dev, VENUS_PAS_ID,
                                                   *mem_phys, *mem_size);
    ...
}

drivers/media/platform/qcom/iris/iris_firmware.c:iris_load_fw_to_memory() {
    ...
    core->pas_ctx = devm_qcom_pas_context_alloc(dev, IRIS_PAS_ID, mem_phys,
                                                resource_size(&res));
    ...
}

These functions are executed repeatedly during normal system operations such as
system suspend/resume (e.g., ath12k_core_resume_early() ->
ath12k_hif_power_up() -> ath12k_ahb_power_up()) and system error recovery
(venus_sys_error_handler, iris_sys_error_handler).

Since devm_* resources are only freed when the driver is unbound, does every
invocation append a new allocation to the devres list without freeing the
previous one?

This would leak memory and degrade devres traversal performance with each
suspend/resume cycle or error recovery.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925155737.4161358-1-mukesh.ojha@oss.qualcomm.com?part=7