* Re: [PATCH v3] dmaengine: dw-axi-dmac: convert to clk bulk APIs
2026-09-02 1:30 [PATCH v3] dmaengine: dw-axi-dmac: convert to clk bulk APIs Li Youhong
@ 2026-09-02 1:45 ` sashiko-bot
2026-09-02 10:57 ` kernel test robot
2026-09-02 19:48 ` kernel test robot
2 siblings, 0 replies; 4+ messages in thread
From: sashiko-bot @ 2026-09-02 1:45 UTC (permalink / raw)
To: Li Youhong; +Cc: vkoul, dmaengine, Frank.Li
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
New issues:
- [High] Unchecked clk_bulk_prepare_enable() in dw_remove() introduces a regression where a partial clock failure guarantees an external abort.
Pre-existing issues:
- [High] Virt-dma tasklets are not killed on probe error paths, risking Use-After-Free if scheduled.
- [High] Premature IRQ registration before channel registers are mapped and clocks are enabled risks NULL pointer dereference and bus faults.
- [High] `dw_remove()` modifies per-channel hardware state without holding the required `chan->vc.lock`, allowing concurrent DMA operations to unsafely re-enable channels.
- [High] The driver relies on devres to unregister the DMA engine asynchronously after `dw_remove()` completes, exposing suspended hardware to concurrent DMA clients.
--
commit 40975e504ffaf6727d542d4c2cde656ef32bc7dc
Author: Li Youhong <liyouhong@kylinos.cn>
dmaengine: dw-axi-dmac: convert to clk bulk APIs
axi_dma_resume() enables cfgr_clk then core_clk. If enabling
core_clk fails, return without disabling cfgr_clk, leaking the
already-enabled clock.
Switch both clocks to the clk bulk helpers so prepare/enable
failures roll back automatically, and update probe/remove/
suspend/resume accordingly.
> diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> index eebed2474210d..cf743450f629e 100644
> --- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> +++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
[ ... ]
> @@ -1524,13 +1519,11 @@ static int dw_probe(struct platform_device *pdev)
>
> chip->dw->hdata->use_cfg2 = !!(flags & AXI_DMA_FLAG_USE_CFG2);
>
> - chip->core_clk = devm_clk_get(chip->dev, "core-clk");
> - if (IS_ERR(chip->core_clk))
> - return PTR_ERR(chip->core_clk);
> -
> - chip->cfgr_clk = devm_clk_get(chip->dev, "cfgr-clk");
> - if (IS_ERR(chip->cfgr_clk))
> - return PTR_ERR(chip->cfgr_clk);
> + chip->clks[0].id = "cfgr-clk";
> + chip->clks[1].id = "core-clk";
> + ret = devm_clk_bulk_get(chip->dev, DW_AXI_DMA_MAX_CLKS, chip->clks);
> + if (ret)
> + return ret;
[Severity: High]
This isn't a bug introduced by this patch, but are the virt-dma tasklets
properly cleaned up if probe fails?
Later in dw_probe(), vchan_init() initializes a tasklet for each channel:
vchan_init(&chan->vc, &dw->dma);
If a subsequent step like dmaenginem_async_device_register() fails, the driver
returns without calling tasklet_kill().
Since devm_request_irq() was called earlier with IRQF_SHARED, a shared
interrupt could fire and schedule the tasklet before the error path completes,
leading to a use-after-free when devres frees the channel memory.
[Severity: High]
This is also a pre-existing issue, but does requesting the shared IRQ early
risk a NULL pointer dereference or bus fault?
In dw_probe(), devm_request_irq() is called with IRQF_SHARED:
ret = axi_req_irqs(pdev, chip);
This happens before the hardware clocks are enabled and before chan->chan_regs
is populated later in dw_probe():
chan->chan_regs = chip->regs + COMMON_REG_LEN + i * CHAN_REG_LEN;
If a shared interrupt fires immediately, dw_axi_dma_interrupt() executes and
calls axi_dma_irq_disable(), which reads DMAC_CFG while clocks are off, causing
a bus fault. It also reads chan->chan_regs + CH_INTSTATUS, which is NULL,
resulting in a crash.
[ ... ]
> @@ -1642,8 +1635,7 @@ static void dw_remove(struct platform_device *pdev)
> u32 i;
>
> /* Enable clk before accessing to registers */
> - clk_prepare_enable(chip->cfgr_clk);
> - clk_prepare_enable(chip->core_clk);
> + clk_bulk_prepare_enable(DW_AXI_DMA_MAX_CLKS, chip->clks);
> axi_dma_irq_disable(chip);
[Severity: High]
Does this unchecked bulk prepare/enable create a regression where a partial
clock failure leads to a bus fault?
During driver removal, if cfgr-clk enables successfully but core-clk fails, the
clk_bulk API automatically rolls back and disables cfgr-clk. Because the return
value isn't checked, the code unconditionally proceeds to call
axi_dma_irq_disable().
axi_dma_irq_disable() reads the DMAC_CFG APB register while the APB clock is
disabled, causing a bus fault.
Before this patch, the individual clk_prepare_enable() calls did not roll back
cfgr-clk on core-clk failure, allowing the APB access to succeed safely.
> for (i = 0; i < dw->hdata->nr_channels; i++) {
> axi_chan_disable(&chip->dw->chan[i]);
[Severity: High]
This is a pre-existing issue, but does this loop unsafely modify hardware
state without holding chan->vc.lock?
In dw_remove(), axi_chan_disable() and axi_chan_irq_disable() are called
without acquiring the lock. Concurrently, a virt-dma tasklet or client can call
axi_chan_start_first_queued(), which acquires the lock and writes to DMAC_CHEN
to enable the channel.
This race could allow a channel to be re-enabled after dw_remove() attempted to
disable it. When dw_remove() subsequently suspends the clocks, it could crash
the bus if the channel is actively transferring.
> axi_chan_irq_disable(&chip->dw->chan[i], DWAXIDMAC_IRQ_ALL);
> }
> axi_dma_disable(chip);
>
> pm_runtime_disable(chip->dev);
> axi_dma_suspend(chip);
>
> for (i = 0; i < DMAC_MAX_CHANNELS; i++)
> if (chip->irq[i] > 0)
> devm_free_irq(chip->dev, chip->irq[i], chip);
[Severity: High]
This isn't a bug introduced by this patch, but does this driver leave
suspended hardware exposed to concurrent DMA clients during unbind?
Because dw_probe() uses dmaenginem_async_device_register() (devm), the DMA
engine is only unregistered asynchronously by devres after dw_remove() fully
returns.
During dw_remove(), the hardware clocks are manually turned off via
axi_dma_suspend(). Since the DMA engine remains visible to clients throughout
this process, a concurrent DMA request invoking dma_chan_issue_pending() will
attempt to write to hardware registers with disabled clocks, leading to a bus
fault.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260902013016.3381788-1-dayou5941@163.com?part=1
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH v3] dmaengine: dw-axi-dmac: convert to clk bulk APIs
2026-09-02 1:30 [PATCH v3] dmaengine: dw-axi-dmac: convert to clk bulk APIs Li Youhong
2026-09-02 1:45 ` sashiko-bot
@ 2026-09-02 10:57 ` kernel test robot
2026-09-02 19:48 ` kernel test robot
2 siblings, 0 replies; 4+ messages in thread
From: kernel test robot @ 2026-09-02 10:57 UTC (permalink / raw)
To: Li Youhong, Eugeniy.Paltsev, vkoul
Cc: oe-kbuild-all, Frank.Li, dmaengine, Li Youhong, Frank Li
Hi Li,
kernel test robot noticed the following build warnings:
[auto build test WARNING on vkoul-dmaengine/next]
[also build test WARNING on linus/master v7.3-rc1 next-20260901]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Li-Youhong/dmaengine-dw-axi-dmac-convert-to-clk-bulk-APIs/20260902-093016
base: https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git next
patch link: https://lore.kernel.org/r/20260902013016.3381788-1-dayou5941%40163.com
patch subject: [PATCH v3] dmaengine: dw-axi-dmac: convert to clk bulk APIs
config: parisc-randconfig-r071-20260902 (https://download.01.org/0day-ci/archive/20260902/202609021848.VdrAqFe1-lkp@intel.com/config)
compiler: hppa-linux-gcc (GCC) 10.5.0
smatch: v0.5.0-9187-g5189e3fb
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260902/202609021848.VdrAqFe1-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202609021848.VdrAqFe1-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c: In function 'dw_remove':
>> drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c:1638:2: warning: ignoring return value of 'clk_bulk_prepare_enable' declared with attribute 'warn_unused_result' [-Wunused-result]
1638 | clk_bulk_prepare_enable(DW_AXI_DMA_MAX_CLKS, chip->clks);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vim +1638 drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
1629
1630 static void dw_remove(struct platform_device *pdev)
1631 {
1632 struct axi_dma_chip *chip = platform_get_drvdata(pdev);
1633 struct dw_axi_dma *dw = chip->dw;
1634 struct axi_dma_chan *chan, *_chan;
1635 u32 i;
1636
1637 /* Enable clk before accessing to registers */
> 1638 clk_bulk_prepare_enable(DW_AXI_DMA_MAX_CLKS, chip->clks);
1639 axi_dma_irq_disable(chip);
1640 for (i = 0; i < dw->hdata->nr_channels; i++) {
1641 axi_chan_disable(&chip->dw->chan[i]);
1642 axi_chan_irq_disable(&chip->dw->chan[i], DWAXIDMAC_IRQ_ALL);
1643 }
1644 axi_dma_disable(chip);
1645
1646 pm_runtime_disable(chip->dev);
1647 axi_dma_suspend(chip);
1648
1649 for (i = 0; i < DMAC_MAX_CHANNELS; i++)
1650 if (chip->irq[i] > 0)
1651 devm_free_irq(chip->dev, chip->irq[i], chip);
1652
1653 of_dma_controller_free(chip->dev->of_node);
1654
1655 list_for_each_entry_safe(chan, _chan, &dw->dma.channels,
1656 vc.chan.device_node) {
1657 list_del(&chan->vc.chan.device_node);
1658 tasklet_kill(&chan->vc.task);
1659 }
1660 }
1661
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH v3] dmaengine: dw-axi-dmac: convert to clk bulk APIs
2026-09-02 1:30 [PATCH v3] dmaengine: dw-axi-dmac: convert to clk bulk APIs Li Youhong
2026-09-02 1:45 ` sashiko-bot
2026-09-02 10:57 ` kernel test robot
@ 2026-09-02 19:48 ` kernel test robot
2 siblings, 0 replies; 4+ messages in thread
From: kernel test robot @ 2026-09-02 19:48 UTC (permalink / raw)
To: Li Youhong, Eugeniy.Paltsev, vkoul
Cc: llvm, oe-kbuild-all, Frank.Li, dmaengine, Li Youhong, Frank Li
Hi Li,
kernel test robot noticed the following build warnings:
[auto build test WARNING on vkoul-dmaengine/next]
[also build test WARNING on linus/master v7.3-rc1 next-20260902]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Li-Youhong/dmaengine-dw-axi-dmac-convert-to-clk-bulk-APIs/20260902-093016
base: https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git next
patch link: https://lore.kernel.org/r/20260902013016.3381788-1-dayou5941%40163.com
patch subject: [PATCH v3] dmaengine: dw-axi-dmac: convert to clk bulk APIs
config: s390-allmodconfig (https://download.01.org/0day-ci/archive/20260903/202609030325.ALAaghFW-lkp@intel.com/config)
compiler: clang version 24.0.0git (https://github.com/llvm/llvm-project ed1626b9d0eaf7c406f44da5fb595ad94559f54b)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260903/202609030325.ALAaghFW-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202609030325.ALAaghFW-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c:1638:2: warning: ignoring return value of function declared with 'warn_unused_result' attribute [-Wunused-result]
1638 | clk_bulk_prepare_enable(DW_AXI_DMA_MAX_CLKS, chip->clks);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
vim +/warn_unused_result +1638 drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
1629
1630 static void dw_remove(struct platform_device *pdev)
1631 {
1632 struct axi_dma_chip *chip = platform_get_drvdata(pdev);
1633 struct dw_axi_dma *dw = chip->dw;
1634 struct axi_dma_chan *chan, *_chan;
1635 u32 i;
1636
1637 /* Enable clk before accessing to registers */
> 1638 clk_bulk_prepare_enable(DW_AXI_DMA_MAX_CLKS, chip->clks);
1639 axi_dma_irq_disable(chip);
1640 for (i = 0; i < dw->hdata->nr_channels; i++) {
1641 axi_chan_disable(&chip->dw->chan[i]);
1642 axi_chan_irq_disable(&chip->dw->chan[i], DWAXIDMAC_IRQ_ALL);
1643 }
1644 axi_dma_disable(chip);
1645
1646 pm_runtime_disable(chip->dev);
1647 axi_dma_suspend(chip);
1648
1649 for (i = 0; i < DMAC_MAX_CHANNELS; i++)
1650 if (chip->irq[i] > 0)
1651 devm_free_irq(chip->dev, chip->irq[i], chip);
1652
1653 of_dma_controller_free(chip->dev->of_node);
1654
1655 list_for_each_entry_safe(chan, _chan, &dw->dma.channels,
1656 vc.chan.device_node) {
1657 list_del(&chan->vc.chan.device_node);
1658 tasklet_kill(&chan->vc.task);
1659 }
1660 }
1661
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 4+ messages in thread