linux/kernel/git/baikal/linux.git, branch dmac/bt1

dmaengine: dw: Fix XFER bit set, but channel not idle error

2026-08-05T23:05:15+00:00

If a client driver gets to use the DW DMAC engine device tougher than usual, with occasional DMA-transfers termination and restart, then the next error can be randomly spotted in the system log: > dma dma0chan0: BUG: XFER bit set, but channel not idle! For instance that happens in case of the 8250 UART port driver handling the looped back high-speed traffic (in my case > 1.5Mbaud) by means of the DMA-engine interface. The error happens due to the two-staged nature of the DW DMAC IRQs handling procedure and due to the critical section break in the meantime. In particular in case if the DMA-transfer is terminated and restarted: 1. after the IRQ-handler submitted the tasklet but before the tasklet started handling the DMA-descriptors in dwc_scan_descriptors(); 2. after the XFER completion flag was detected in the dwc_scan_descriptors() method, but before the dwc_complete_all() method is called the error denoted above is printed due to the overlap of the last transfer completion and the new transfer execution stages. There are two places need to be altered in order to fix the problem. 1. Clear the IRQs in the dwc_chan_disable() method. That will prevent the dwc_scan_descriptors() method call in case if the DMA-transfer is restarted in the middle of the two-staged IRQs-handling procedure. 2. Move the dwc_complete_all() code to being executed inseparably (in the same atomic section) from the DMA-descriptors scanning procedure. That will prevent the DMA-transfer restarts after the DMA-transfer completion was spotted but before the actual completion is executed. Fixes: 69cea5a00d31 ("dmaengine/dw_dmac: Replace spin_lock* with irqsave variants and enable submission from callback") Fixes: 3bfb1d20b547 ("dmaengine: Driver for the Synopsys DesignWare DMA controller") Signed-off-by: Serge Semin

dmaengine: dw: Prevent tx-status calling DMA-desc callback

2026-08-05T23:05:15+00:00

The dmaengine_tx_status() method implemented in the DW DMAC driver is responsible for not just DMA-transfer status getting, but may also cause the transfer finalization with the Tx-descriptors callback invocation. This makes the simple DMA-transfer status getting being much more complex than it seems with a wider room for possible bugs. In particular a deadlock has been discovered in the DW 8250 UART device driver interacting with the DW DMA controller channels. Here is the call-trace causing the deadlock: serial8250_handle_irq() uart_port_lock_irqsave(port); ----------------------+ handle_rx_dma() | serial8250_rx_dma_flush() | __dma_rx_complete() | dmaengine_tx_status() | dwc_scan_descriptors() | dwc_complete_all() | dwc_descriptor_complete() | dmaengine_desc_callback_invoke() | cb->callback(cb->callback_param); | || | dma_rx_complete(); | uart_port_lock_irqsave(port); ----+ <- Deadlock! So in case if the DMA-engine finished working at some point before the serial8250_rx_dma_flush() invocation and the respective tasklet hasn't been executed yet to finalize the DMA transfer, then calling the dmaengine_tx_status() will cause the DMA-descriptors status update and the Tx-descriptor callback invocation. Generalizing the case up: if the dmaengine_tx_status() method callee and the Tx-descriptor callback refer to the related critical section, then calling dmaengine_tx_status() from the Tx-descriptor callback will inevitably cause a deadlock around the guarding lock as it happens in the Serial 8250 DMA implementation above. (Note the deadlock doesn't happen very often, but can be eventually discovered if the being received data size is greater than the Rx DMA-buffer size defined in the 8250_dma.c driver. In my case reducing the Rx DMA-buffer size increased the deadlock probability.) Alas there is no obvious way to prevent the deadlock by fixing the 8250-port drivers because the UART-port lock must be held for the entire port IRQ handling procedure. Thus the best way to fix the discovered problem (and prevent similar ones in the drivers using the DW DMAC device channels) is to simplify the DMA-transfer status getter by removing the Tx-descriptors state update from there and making the function to serve just one purpose - calculate the DMA-transfer residue and return the transfer status. The DMA-transfer status update will be performed in the bottom-half procedure only. Fixes: 3bfb1d20b547 ("dmaengine: Driver for the Synopsys DesignWare DMA controller") Signed-off-by: Serge Semin --- Changelog RFC: - Instead of just dropping the dwc_scan_descriptors() method invocation calculate the residue in the Tx-status getter.

dt-bindings: dmaengine: Add Baikal-T1 DMA Controller binding

2026-08-05T23:05:15+00:00

Baikal-T1 is equipped with DW APB DMAC IP-core of v2.14a with eight slave channels and two master channels. First master is directed towards the system memory thus it has up to 16 byte data bus width, while the second master is supposed to work with the low-speed devices and has only 4 data bytes bus. TS block is limited with 4095 bytes with no linked-lists support (sadly). Max burst length equals to 16 bytes on the first and second channels, and 4 bytes - on the rest of them. The DMA engine has hand-shaking interface attached to the next low-speed peripherals: 1) UART controller: requests #0, #1, #2, #3; 2) SPI controller: requests #4, #5, #6, #7; 3) I2C controller: requests #8, #9, #10, #11. Signed-off-by: Serge Semin

Linux 7.0

2026-04-12T20:48:06+00:00

Merge tag 'edac_urgent_for_7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras

2026-04-12T18:56:07+00:00

Pull EDAC fix from Borislav Petkov: - Fix the error path ordering when the driver-private descriptor allocation fails * tag 'edac_urgent_for_7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/mc: Fix error path ordering in edac_mc_alloc()

Merge tag 'wq-for-7.0-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq

2026-04-12T17:42:40+00:00

Pull workqueue fix from Tejun Heo: "This is a fix for a stall which triggers on ordered workqueues when there are multiple inactive work items during workqueue property changes through sysfs, which doesn't happen that frequently. While really late, the fix is very low risk as it just repeats an operation which is already being performed: - Fix incomplete activation of multiple inactive works when unplugging a pool_workqueue, where the pending_pwqs list wasn't being updated for subsequent works" * tag 'wq-for-7.0-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: Add pool_workqueue to pending_pwqs list when unplugging multiple inactive works

Merge tag 'timers-urgent-2026-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-04-12T17:01:55+00:00

Pull timer fixes from Thomas Gleixner: "Two fixes for the time/timers subsystem: - Invert the inverted fastpath decision in check_tick_dependency(), which prevents NOHZ full to stop the tick. That's a regression introduced in the 7.0 merge window. - Prevent a unpriviledged DoS in the clockevents code, where user space can starve the timer interrupt by arming a timerfd or posix interval timer in a tight loop with an absolute expiry time in the past. The fix turned out to be incomplete and was was amended yesterday to make it work on some 20 years old AMD machines as well. All issues with it have been confirmed to be resolved by various reporters" * tag 'timers-urgent-2026-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: clockevents: Prevent timer interrupt starvation tick/nohz: Fix inverted return value in check_tick_dependency() fast path

Merge tag 'sched-urgent-2026-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-04-12T15:30:20+00:00

Pull scheduler fix from Ingo Molnar: "Fix DL server related slowdown to deferred fair tasks" * tag 'sched-urgent-2026-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/deadline: Use revised wakeup rule for dl_server

Merge tag 'ras-urgent-2026-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-04-12T15:27:09+00:00

Pull x86 MCE fix from Ingo Molnar: "Fix incorrect hardware errors reported on Zen3 CPUs, such as bogus L3 cache deferred errors (Yazen Ghannam)" * tag 'ras-urgent-2026-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mce/amd: Filter bogus hardware errors on Zen3 clients

Merge tag 'perf-urgent-2026-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-04-12T15:17:52+00:00

Pull perf fixes from Ingo Molnar: "Four Intel uncore PMU driver fixes by Zide Chen" * tag 'perf-urgent-2026-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel/uncore: Remove extra double quote mark perf/x86/intel/uncore: Fix die ID init and look up bugs perf/x86/intel/uncore: Skip discovery table for offline dies perf/x86/intel/uncore: Fix iounmap() leak on global_init failure