kernel/linux.git/drivers/dma/qcom, branch v5.15.209

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

2026-02-06T15:41:50+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-10-02T11:39:04+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

dma: gpi: remove spurious unlock in gpi_ch_init

2023-05-11T14:00:38+00:00

[ Upstream commit 91d6a468e335571f1e67e046050dea9af5fa4ebe ] gpi_ch_init() doesn't lock the ctrl_lock mutex, so there is no need to unlock it too. Instead the mutex is handled by the function gpi_alloc_chan_resources(), which properly locks and unlocks the mutex. ===================================== WARNING: bad unlock balance detected! 6.3.0-rc5-00253-g99792582ded1-dirty #15 Not tainted ------------------------------------- kworker/u16:0/9 is trying to release lock (&gpii->ctrl_lock) at: [] gpi_alloc_chan_resources+0x108/0x5bc but there are no more locks to release! other info that might help us debug this: 6 locks held by kworker/u16:0/9: #0: ffff575740010938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x220/0x594 #1: ffff80000809bdd0 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work+0x220/0x594 #2: ffff575740f2a0f8 (&dev->mutex){....}-{3:3}, at: __device_attach+0x38/0x188 #3: ffff57574b5570f8 (&dev->mutex){....}-{3:3}, at: __device_attach+0x38/0x188 #4: ffffb99d06a2f180 (of_dma_lock){+.+.}-{3:3}, at: of_dma_request_slave_channel+0x138/0x280 #5: ffffb99d06a2ee20 (dma_list_mutex){+.+.}-{3:3}, at: dma_get_slave_channel+0x28/0x10c stack backtrace: CPU: 7 PID: 9 Comm: kworker/u16:0 Not tainted 6.3.0-rc5-00253-g99792582ded1-dirty #15 Hardware name: Google Pixel 3 (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0xa0/0xfc show_stack+0x18/0x24 dump_stack_lvl+0x60/0xac dump_stack+0x18/0x24 print_unlock_imbalance_bug+0x130/0x148 lock_release+0x270/0x300 __mutex_unlock_slowpath+0x48/0x2cc mutex_unlock+0x20/0x2c gpi_alloc_chan_resources+0x108/0x5bc dma_chan_get+0x84/0x188 dma_get_slave_channel+0x5c/0x10c gpi_of_dma_xlate+0x110/0x1a0 of_dma_request_slave_channel+0x174/0x280 dma_request_chan+0x3c/0x2d4 geni_i2c_probe+0x544/0x63c platform_probe+0x68/0xc4 really_probe+0x148/0x2ac __driver_probe_device+0x78/0xe0 driver_probe_device+0x3c/0x160 __device_attach_driver+0xb8/0x138 bus_for_each_drv+0x84/0xe0 __device_attach+0x9c/0x188 device_initial_probe+0x14/0x20 bus_probe_device+0xac/0xb0 device_add+0x60c/0x7d8 of_device_add+0x44/0x60 of_platform_device_create_pdata+0x90/0x124 of_platform_bus_create+0x15c/0x3c8 of_platform_populate+0x58/0xf8 devm_of_platform_populate+0x58/0xbc geni_se_probe+0xf0/0x164 platform_probe+0x68/0xc4 really_probe+0x148/0x2ac __driver_probe_device+0x78/0xe0 driver_probe_device+0x3c/0x160 __device_attach_driver+0xb8/0x138 bus_for_each_drv+0x84/0xe0 __device_attach+0x9c/0x188 device_initial_probe+0x14/0x20 bus_probe_device+0xac/0xb0 deferred_probe_work_func+0x8c/0xc8 process_one_work+0x2bc/0x594 worker_thread+0x228/0x438 kthread+0x108/0x10c ret_from_fork+0x10/0x20 Fixes: 5d0c3533a19f ("dmaengine: qcom: Add GPI dma driver") Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20230409233355.453741-1-dmitry.baryshkov@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: qcom: bam_dma: fix runtime PM underflow

2022-07-12T14:35:18+00:00

commit 0ac9c3dd0d6fe293cd5044cfad10bec27d171e4e upstream. Commit dbad41e7bb5f ("dmaengine: qcom: bam_dma: check if the runtime pm enabled") caused unbalanced pm_runtime_get/put() calls when the bam is controlled remotely. This commit reverts it and just enables pm_runtime in all cases, the clk_* functions already just nop when the clock is NULL. Also clean up a bit by removing unnecessary bamclk null checks. Suggested-by: Stephan Gerhold Fixes: dbad41e7bb5f ("dmaengine: qcom: bam_dma: check if the runtime pm enabled") Signed-off-by: Caleb Connolly Link: https://lore.kernel.org/r/20220629140559.118537-1-caleb.connolly@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman

Merge tag 'dmaengine-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine

2021-07-05T19:05:13+00:00

Pull dmaengine updates from Vinod Koul: "This time around we have a smaller pull request than usual and this includes code removal, so should be good! New drivers/devices - Support for QCOM SM8250 GPI DMA - removal of shdma-of driver and binding Updates: - arm-pl08x yaml binding move - altera-msgdma gained DT support - removal of imx-sdma platform data support - idxd and xilinx driver updates" * tag 'dmaengine-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: (22 commits) dmaengine: imx-sdma: Remove platform data header dmaengine: xilinx: dpdma: Fix spacing around addr[i-1] dmaengine: xilinx: dpdma: Use kernel type u32 over uint32_t dmaengine: altera-msgdma: add OF support MAINTAINERS: add entry for Altera mSGDMA dt-bindings: dma: add schema for altera-msgdma dmaengine: xilinx: dpdma: fix kernel-doc dmaengine: sf-pdma: apply proper spinlock flags in sf_pdma_prep_dma_memcpy() dmaengine: sh: Remove unused shdma-of driver dt-bindings: dmaengine: Remove SHDMA Device Tree bindings dmaengine: qcom: gpi: Add SM8250 compatible dt-bindings: dmaengine: qcom: gpi: add compatible for sm8250 dmaengine: sun4i: Use list_move_tail instead of list_del/list_add_tail dmaengine: ti: omap-dma: Skip pointless cpu_pm context restore on errors dmaengine: hsu: Account transferred bytes dmaengine: Move kdoc description of struct dma_chan_percpu closer to it dmaengine: xilinx: dpdma: Print debug message when losing vsync race dmaengine: xilinx: dpdma: Print channel number in kernel log messages dt-bindings: dma: convert arm-pl08x to yaml dmaengine: idxd: remove devm allocation for idxd->int_handles ...

Merge tag 'dmaengine-fix-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine

2021-06-16T16:03:52+00:00

Pull dmaengine fixes from Vinod Koul: "A bunch of driver fixes, notably: - More idxd fixes for driver unregister, error handling and bus assignment - HAS_IOMEM depends fix for few drivers - lock fix in pl330 driver - xilinx drivers fixes for initialize registers, missing dependencies and limiting descriptor IDs - mediatek descriptor management fixes" * tag 'dmaengine-fix-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: dmaengine: mediatek: use GFP_NOWAIT instead of GFP_ATOMIC in prep_dma dmaengine: mediatek: do not issue a new desc if one is still current dmaengine: mediatek: free the proper desc in desc_free handler dmaengine: ipu: fix doc warning in ipu_irq.c dmaengine: rcar-dmac: Fix PM reference leak in rcar_dmac_probe() dmaengine: idxd: Fix missing error code in idxd_cdev_open() dmaengine: stedma40: add missing iounmap() on error in d40_probe() dmaengine: SF_PDMA depends on HAS_IOMEM dmaengine: QCOM_HIDMA_MGMT depends on HAS_IOMEM dmaengine: ALTERA_MSGDMA depends on HAS_IOMEM dmaengine: idxd: Add missing cleanup for early error out in probe call dmaengine: xilinx: dpdma: Limit descriptor IDs to 16 bits dmaengine: xilinx: dpdma: Add missing dependencies to Kconfig dmaengine: stm32-mdma: fix PM reference leak in stm32_mdma_alloc_chan_resourc() dmaengine: zynqmp_dma: Fix PM reference leak in zynqmp_dma_alloc_chan_resourc() dmaengine: xilinx: dpdma: initialize registers before request_irq dmaengine: pl330: fix wrong usage of spinlock flags in dma_cyclc dmaengine: fsl-dpaa2-qdma: Fix error return code in two functions dmaengine: idxd: add missing dsa driver unregister dmaengine: idxd: add engine 'struct device' missing bus type assignment

dmaengine: qcom: gpi: Add SM8250 compatible

2021-06-16T10:36:10+00:00

SM8250 seems to work just fine, so add a shiny new compatible for it. Signed-off-by: Konrad Dybcio Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210614235358.444834-2-konrad.dybcio@somainline.org Signed-off-by: Vinod Koul

dmaengine: QCOM_HIDMA_MGMT depends on HAS_IOMEM

2021-05-31T04:14:14+00:00

When CONFIG_HAS_IOMEM is not set/enabled, certain iomap() family functions [including ioremap(), devm_ioremap(), etc.] are not available. Drivers that use these functions should depend on HAS_IOMEM so that they do not cause build errors. Rectifies these build errors: s390-linux-ld: drivers/dma/qcom/hidma_mgmt.o: in function `hidma_mgmt_probe': hidma_mgmt.c:(.text+0x780): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/dma/qcom/hidma_mgmt.o: in function `hidma_mgmt_init': hidma_mgmt.c:(.init.text+0x126): undefined reference to `of_address_to_resource' s390-linux-ld: hidma_mgmt.c:(.init.text+0x16e): undefined reference to `of_address_to_resource' Fixes: 67a2003e0607 ("dmaengine: add Qualcomm Technologies HIDMA channel driver") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Sinan Kaya Cc: Vinod Koul Cc: dmaengine@vger.kernel.org Link: https://lore.kernel.org/r/20210522021313.16405-3-rdunlap@infradead.org Signed-off-by: Vinod Koul

dmaengine: qcom_hidma: comment platform_driver_register call

2021-05-13T16:32:29+00:00

Place a comment in hidma_mgmt_init explaining why success must currently be assumed, due to the cleanup issue that would need to be considered were this module ever to be unloadable or were this platform_driver_register call ever to fail. Acked-By: Vinod Koul Acked-By: Sinan Kaya Signed-off-by: Phillip Potter Link: https://lore.kernel.org/r/20210503115736.2104747-52-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

Revert "dmaengine: qcom_hidma: Check for driver register failure"

2021-05-13T16:32:28+00:00

This reverts commit a474b3f0428d6b02a538aa10b3c3b722751cb382. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. The original change is NOT correct, as it does not correctly unwind from the resources that was allocated before the call to platform_driver_register(). Cc: Aditya Pakki Acked-By: Vinod Koul Acked-By: Sinan Kaya Link: https://lore.kernel.org/r/20210503115736.2104747-51-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman