kernel/linux.git/drivers/dma/qcom, branch v6.6.132

dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config()

2026-01-30T09:27:29+00:00

commit 3f747004bbd641131d9396d87b5d2d3d1e182728 upstream. Fix a memory leak in gpi_peripheral_config() where the original memory pointed to by gchan->config could be lost if krealloc() fails. The issue occurs when: 1. gchan->config points to previously allocated memory 2. krealloc() fails and returns NULL 3. The function directly assigns NULL to gchan->config, losing the reference to the original memory 4. The original memory becomes unreachable and cannot be freed Fix this by using a temporary variable to hold the krealloc() result and only updating gchan->config when the allocation succeeds. Found via static analysis and code review. Fixes: 5d0c3533a19f ("dmaengine: qcom: Add GPI dma driver") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin Reviewed-by: Bjorn Andersson Link: https://patch.msgid.link/20251029123421.91973-1-linmq006@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman

dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees

2025-09-19T14:32:07+00:00

commit 5068b5254812433e841a40886e695633148d362d upstream. When we don't have a clock specified in the device tree, we have no way to ensure the BAM is on. This is often the case for remotely-controlled or remotely-powered BAM instances. In this case, we need to read num-channels from the DT to have all the necessary information to complete probing. However, at the moment invalid device trees without clock and without num-channels still continue probing, because the error handling is missing return statements. The driver will then later try to read the number of channels from the registers. This is unsafe, because it relies on boot firmware and lucky timing to succeed. Unfortunately, the lack of proper error handling here has been abused for several Qualcomm SoCs upstream, causing early boot crashes in several situations [1, 2]. Avoid these early crashes by erroring out when any of the required DT properties are missing. Note that this will break some of the existing DTs upstream (mainly BAM instances related to the crypto engine). However, clearly these DTs have never been tested properly, since the error in the kernel log was just ignored. It's safer to disable the crypto engine for these broken DTBs. [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/ [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/ Cc: stable@vger.kernel.org Fixes: 48d163b1aa6e ("dmaengine: qcom: bam_dma: get num-channels and num-ees from dt") Signed-off-by: Stephan Gerhold Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250212-bam-dma-fixes-v1-8-f560889e65d8@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman

dmaengine: Explicitly include correct DT includes

2023-08-01T18:21:27+00:00

The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20230718143138.1066177-1-robh@kernel.org Signed-off-by: Vinod Koul

dmaengine: qcom: hidma_mgmt: Use devm_platform_get_and_ioremap_resource()

2023-07-12T16:54:00+00:00

Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by: Yangtao Li Link: https://lore.kernel.org/r/20230705081856.13734-3-frank.li@vivo.com Signed-off-by: Vinod Koul

dmaengine: qcom_hidma: Use devm_platform_get_and_ioremap_resource()

2023-07-12T16:54:00+00:00

dmaengine: qcom: gpi: Use devm_platform_get_and_ioremap_resource()

2023-07-12T16:54:00+00:00

dmaengine: hidma: Don't set chancnt

2023-05-24T06:54:32+00:00

The dma framework will calculate the dma channels chancnt, setting it ourself is wrong. Signed-off-by: Jisheng Zhang Link: https://lore.kernel.org/r/20230521100252.3197-5-jszhang@kernel.org Signed-off-by: Vinod Koul

dmaengine: qcom: bam_dma: allow omitting num-{channels,ees}

2023-05-24T06:52:43+00:00

The bam_dma driver needs to know the number of channels and execution environments (EEs) at probe time. If we are in full control of the BAM controller this information can be obtained from the BAM identification registers (BAM_REVISION/BAM_NUM_PIPES). When the BAM is "controlled remotely" it is more complicated. The BAM might not be on at probe time, so reading the registers could fail. This is why the information must be added to the device tree in this case, using "num-channels" and "qcom,num-ees". However, there are also some BAM instances that are initialized by something else but we still have a clock that allows to turn it on when needed. This can be set up in the DT with "qcom,controlled-remotely" and "clocks" and is already supported by the bam_dma driver. Examples for this are the typical BLSP BAM instances on older SoCs, QPIC BAM (for NAND) and the crypto BAM on some SoCs. In this case, there is no need to read "num-channels" and "qcom,num-ees" from the DT. The BAN can be turned on using the clock so we can just read it from the BAM registers like in the normal case. Check for the BAM clock earlier and skip reading "num-channels" and "qcom,num-ees" if it is present to allow simplifying the DT description a bit. Signed-off-by: Stephan Gerhold Reviewed-by: Bhupesh Sharma Link: https://lore.kernel.org/r/20230518-bamclk-dt-v2-1-a1a857b966ca@gerhold.net Signed-off-by: Vinod Koul

dmaengine: make QCOM_HIDMA depend on HAS_IOMEM

2023-05-18T11:31:17+00:00

On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available. Here let QCOM_HIDMA depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset. -------------------------------------------------------- ld: drivers/dma/qcom/hidma.o: in function `hidma_probe': hidma.c:(.text+0x4b46): undefined reference to `devm_ioremap_resource' ld: hidma.c:(.text+0x4b9e): undefined reference to `devm_ioremap_resource' make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 1 make: *** [Makefile:1264: vmlinux] Error 2 Signed-off-by: Baoquan He Reviewed-by: Niklas Schnelle Cc: Andy Gross Cc: Bjorn Andersson Cc: Konrad Dybcio Cc: Vinod Koul Cc: linux-arm-msm@vger.kernel.org Cc: dmaengine@vger.kernel.org Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20230506111628.712316-3-bhe@redhat.com Signed-off-by: Vinod Koul

dmaengine: qcom_hidma: Add explicit platform_device.h and of_device.h includes

2023-04-12T17:13:08+00:00

qcom_hidma uses of_dma_configure() which is declared in of_device.h. platform_device.h and of_device.h get implicitly included by of_platform.h, but that is going to be removed soon. Signed-off-by: Rob Herring Acked-by: Sinan Kaya Link: https://lore.kernel.org/r/20230410232654.1561462-1-robh@kernel.org Signed-off-by: Vinod Koul