kernel/git/next/linux-next.git/drivers/dma, branch master

Merge branch 'next' of https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git

2026-07-06T13:54:39+00:00

Merge branch 'fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git

2026-07-06T13:02:20+00:00

Replace by more specific (c files)

2026-07-03T05:38:17+00:00

Replace the #include of by the more specific where applicable. For most cases the include can be dropped completely, only a few drivers need one or two headers added. Acked-by: Danilo Krummrich Acked-by: Takashi Sakamoto Acked-by: Bjorn Helgaas Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub)

dmaengine: pl330: remove debugfs file on teardown

2026-07-02T15:44:56+00:00

init_pl330_debugfs() creates a debugfs file with struct pl330_dmac as private data. pl330_remove() then unregisters the DMA device and frees the PL330 channel/thread state without removing that file. Keep the debugfs dentry and remove it before tearing down the DMAC state used by the debugfs show callback. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260615091645.28878-1-pengpeng@iscas.ac.cn Signed-off-by: Vinod Koul

dmaengine: dw-axi-dmac: fix __le32 on set of CH_CTL_H_LLI_VALID

2026-07-02T15:43:58+00:00

When writing the lli->ctl_hi, this is an __le32 type so the value being orred should be convered to __le32 by cpu_to_le32. Fixes 1deb96c0fa58a ("dmaegine: dw-axi-dmac: Support device_prep_dma_cyclic()") -- Note, the call to axi_chan_irq_clear() is passing lli->status_lo through which is also an __le32 but it does not seem to be set anywhere. Is this also a bug? Signed-off-by: Ben Dooks Link: https://patch.msgid.link/20260617084944.705266-1-ben.dooks@codethink.co.uk Signed-off-by: Vinod Koul

dmaengine: xilinx_dma: Rename XILINX_DMA_LOOP_COUNT

2026-07-02T15:43:10+00:00

Rename XILINX_DMA_LOOP_COUNT to XILINX_DMA_POLL_TIMEOUT_US because it is a timeout value, not a loop count for polling register in microseconds. No functional changes. Reviewed-by: Suraj Gupta Signed-off-by: Alex Bereza Link: https://patch.msgid.link/20260402-fix-atomic-poll-timeout-regression-v4-2-f30d6a6c13cb@bereza.email Signed-off-by: Vinod Koul

dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout

2026-07-02T15:43:10+00:00

Currently when calling xilinx_dma_poll_timeout with delay_us=0 and a condition that is never fulfilled, the CPU busy-waits for prolonged time and the timeout triggers only with a massive delay causing a CPU stall. This happens due to a huge underestimation of wall clock time in poll_timeout_us_atomic. Commit 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()") changed the behavior to no longer use ktime_get at the expense of underestimation of wall clock time which appears to be very large for delay_us=0. Instead of timing out after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout takes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for loop in poll_timeout_us_atomic takes) which is in the range of several minutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero value for delay_us. Use delay_us=10 to keep the delay in the hot path of starting DMA transfers minimal but still avoid CPU stalls in case of unexpected hardware failures. One-off measurement with delay_us=0 causes the cpu to busy wait around 7 minutes in the timeout case. After applying this patch with delay_us=10 the measured timeout was 1053428 microseconds which is roughly equivalent to the expected 1000000 microseconds specified in XILINX_DMA_LOOP_COUNT. Add a constant XILINX_DMA_POLL_DELAY_US for delay_us value. Fixes: 9495f2648287 ("dmaengine: xilinx_vdma: Use readl_poll_timeout instead of do while loop's") Fixes: 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()") Reviewed-by: Suraj Gupta Reviewed-by: Frank Li Signed-off-by: Alex Bereza Link: https://patch.msgid.link/20260402-fix-atomic-poll-timeout-regression-v4-1-f30d6a6c13cb@bereza.email Signed-off-by: Vinod Koul

dmaengine: hisilicon: Return -ENOMEM on dynamic memory allocation in probe

2026-07-02T15:42:29+00:00

Out of memory situation on driver's probe is expected to be reported to the driver's framework with a proper -ENOMEM error code. Fixes: e9f08b65250d ("dmaengine: hisilicon: Add Kunpeng DMA engine support") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Frank Li Link: https://patch.msgid.link/20260630144214.4080302-1-vz@kernel.org Signed-off-by: Vinod Koul

dmaengine: zynqmp_dma: fix kernel doc for zynqmp_dma_remove()

2026-07-02T15:41:50+00:00

The zynqmp_dma_remove() function was converted from returning int to void, but the kernel doc comment was not updated to reflect this change. Remove the stale "Return: Always '0'" documentation that no longer applies to the void function. Fixes: b1c50ac25425 ("dmaengine: xilinx: zynqmp_dma: Convert to platform remove callback returning void") Signed-off-by: Golla Nagendra Reviewed-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260630064844.705173-3-nagendra.golla@amd.com Signed-off-by: Vinod Koul

dmaengine: zynqmp_dma: fix race between runtime PM and device removal

2026-07-02T15:41:50+00:00

In zynqmp_dma_remove(), runtime PM was disabled only after checking state and doing a manual suspend. This can race with runtime PM in the remove/unbind (rmmod) path. Disable runtime PM first, then suspend only if the device is not already suspended. To prevent any further runtime PM transitions. Fixes: 72dd8b2914b5 ("dmaengine: zynqmp_dma: Add shutdown operation support") Co-developed-by: Prasanna Kumar T S M Signed-off-by: Prasanna Kumar T S M Signed-off-by: Golla Nagendra Reviewed-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260630064844.705173-2-nagendra.golla@amd.com Signed-off-by: Vinod Koul