kernel/git/stable/linux.git/drivers/dma/qcom, branch linux-6.6.y

dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal

2026-09-14T11:29:43+00:00

[ Upstream commit a50184171235045d96104811414b25cf5338cf86 ] bam_dma_probe() calls pm_runtime_use_autosuspend(), but bam_dma_remove() does not call the matching pm_runtime_dont_use_autosuspend() when removing the device. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call before forcing the device into runtime suspend during removal. This issue was found by manual code inspection. Fixes: 7d2545599f5b ("dmaengine: qcom-bam-dma: Add pm_runtime support") Signed-off-by: Guangshuo Li Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260808110642.2770355-1-lgs201920130244@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: qcom: gpi: set DMA_PRIVATE capability

2026-07-24T14:03:15+00:00

[ Upstream commit 4e351f408743354d54ee1af5193fc78234f2044e ] The GPI DMA controller is only responsible for QUP peripherals, and cannot work as a general-purpose DMA accelerator. Set DMA_PRIVATE capability for it. This fixes error messages about GPI being shown when an async-tx consumer is loaded. Fixes: 5d0c3533a19f ("dmaengine: qcom: Add GPI dma driver") Signed-off-by: Icenowy Zheng Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20260602070344.3707256-1-zhengxingda@iscas.ac.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

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