[PATCH v3] ASoC: soc-generic-dmaengine: Handle DMA channel request failures correctly

[PATCH v3] ASoC: soc-generic-dmaengine: Handle DMA channel request failures correctly

[phucduc.bui]

From: bui duc phuc <phucduc.bui@gmail.com>

Currently any dma_request_chan() failure other than -EPROBE_DEFER is
silently ignored, since a missing channel is expected for devices that
only support one DMA direction.

Improve the handling of these failures by:
- reporting failures when a configured DMA channel cannot be requested;
- failing probe if neither playback nor capture obtains a DMA channel,
  since the PCM device would be unusable.

Devices that legitimately support only one DMA direction continue to
work as before.

Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---

Changes in v3:
 - Drop has_legacy_config, since config->chan_names[] only provides the
   requested channel name and does not indicate legacy DMA mapping.
Changes in v2:
 - Update the commit message and title.
 - Refine DMA channel request failure handling to match the
   dma_request_chan() implementation.

 sound/soc/soc-generic-dmaengine-pcm.c | 28 +++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c
index 467426d2b5e4..98ba9a836936 100644
--- a/sound/soc/soc-generic-dmaengine-pcm.c
+++ b/sound/soc/soc-generic-dmaengine-pcm.c
@@ -3,6 +3,7 @@
 //  Copyright (C) 2013, Analog Devices Inc.
 //	Author: Lars-Peter Clausen <lars@metafoo.de>
 
+#include <linux/acpi.h>
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/dmaengine.h>
@@ -395,6 +396,27 @@ static int dmaengine_pcm_request_chan_of(struct dmaengine_pcm *pcm,
 			 */
 			if (PTR_ERR(chan) == -EPROBE_DEFER)
 				return -EPROBE_DEFER;
+
+			bool has_fw_node = dev->of_node || is_acpi_device_node(dev->fwnode);
+			bool name_exists_in_fw = false;
+
+			if (has_fw_node)
+				name_exists_in_fw = device_property_match_string(dev,
+										 "dma-names",
+										 name) >= 0;
+
+			if (has_fw_node && name_exists_in_fw)
+				dev_warn(dev, "DTS/ACPI DMA channel '%s' request failed (%ld)\n",
+					 name, PTR_ERR(chan));
+
+			if (has_fw_node && !name_exists_in_fw)
+				dev_warn(dev, "DTS/ACPI name '%s' not found, legacy failed (%ld)\n",
+					 name, PTR_ERR(chan));
+
+			if (!has_fw_node)
+				dev_warn(dev, "Legacy DMA channel '%s' request failed (%ld)\n",
+					 name, PTR_ERR(chan));
+
 			pcm->chan[i] = NULL;
 		} else {
 			pcm->chan[i] = chan;
@@ -406,6 +428,12 @@ static int dmaengine_pcm_request_chan_of(struct dmaengine_pcm *pcm,
 	if (pcm->flags & SND_DMAENGINE_PCM_FLAG_HALF_DUPLEX)
 		pcm->chan[1] = pcm->chan[0];
 
+	if (!pcm->chan[0] &&
+	    !pcm->chan[1]) {
+		dev_err(dev, "no DMA channel found for either playback or capture\n");
+		return -ENODEV;
+	}
+
 	return 0;
 }
 
-- 
2.43.0

Re: [PATCH v3] ASoC: soc-generic-dmaengine: Handle DMA channel request failures correctly

[Mark Brown]

On Mon, 20 Jul 2026 13:41:31 +0700, phucduc.bui@gmail.com wrote:
> ASoC: soc-generic-dmaengine: Handle DMA channel request failures correctly

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.3

Thanks!

[1/1] ASoC: soc-generic-dmaengine: Handle DMA channel request failures correctly
      https://git.kernel.org/broonie/sound/c/9167f260477b

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Re: [PATCH v3] ASoC: soc-generic-dmaengine: Handle DMA channel request failures correctly

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

Hi,

The new warning triggers for the Rockchip SPDIF driver [0], which
is playback only and thus only has a 'tx' DMA channel:

[    2.275100] rockchip-spdif 27ea0000.spdif-tx: DTS/ACPI name 'rx' not found, legacy failed (-19)

This is from RK3576 Sige5, which does not yet have the node enabled
upstream. But it should be exactly the same for any RK3576, RK3588
or RK3568 board at least.

[0] sound/soc/rockchip/rockchip_spdif.c

Greetings,

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3] ASoC: soc-generic-dmaengine: Handle DMA channel request failures correctly

[Bui Duc Phuc]

Hi Sebastian, Mark,

Thanks for the report, and apologies for the regression.

>
> The new warning triggers for the Rockchip SPDIF driver [0], which
> is playback only and thus only has a 'tx' DMA channel:
>
> [    2.275100] rockchip-spdif 27ea0000.spdif-tx: DTS/ACPI name 'rx' not found, legacy failed (-19)
>
> This is from RK3576 Sige5, which does not yet have the node enabled
> upstream. But it should be exactly the same for any RK3576, RK3588
> or RK3568 board at least.
>
> [0] sound/soc/rockchip/rockchip_spdif.c


The if (has_fw_node && !name_exists_in_fw) branch is not handled correctly.
For DT-only devices (such as Rockchip), this branch can end up propagating
the -ENODEV error coming from the DTS/ACPI stage itself, i.e. the case where
the name simply doesn't exist in dma-names (which is exactly what
name_exists_in_fw is meant to capture), rather than actually reflecting a
legacy-filter-map failure, as the message currently implies.

The more accurate fix would be to also filter out the -ENODEV returned by
of_dma_request_slave_channel() and acpi_dma_request_slave_chan_by_name()
when the name isn't found. However, acpi_dma_request_slave_chan_by_name()
internally calls acpi_dev_get_resources(), so the returned error isn't
guaranteed to
always be -ENODEV. It could be a different error from the resource-parsing step.

In addition, for genuine legacy-path failures, find_candidate()
already logs the failure itself:

--------------------------------------
if (err) {
        if (err == -ENODEV) {
                dev_dbg(device->dev, "%s: %s module removed\n",
                               __func__, dma_chan_name(chan));
                list_del_rcu(&device->global_node);
        } else
                dev_dbg(device->dev,
                               "%s: failed to get %s: (%d)\n",
                               __func__, dma_chan_name(chan), err);

        if (--device->privatecnt == 0)
               dma_cap_clear(DMA_PRIVATE, device->cap_mask);

        chan = ERR_PTR(err);
}

------------------------------------

So, to avoid duplicate logging as well as logging with an inaccurate
or misleading source,
I'll drop these two branches:

+                       if (has_fw_node && !name_exists_in_fw)
+                               dev_warn(dev, "DTS/ACPI name '%s' not
found, legacy failed (%ld)\n",
+                                        name, PTR_ERR(chan));
+
+                       if (!has_fw_node)
+                               dev_warn(dev, "Legacy DMA channel '%s'
request failed (%ld)\n",
+                                        name, PTR_ERR(chan));
+

and keep only:

+                       if (has_fw_node && name_exists_in_fw)
+                               dev_warn(dev, "DTS/ACPI DMA channel
'%s' request failed (%ld)\n",
+                                        name, PTR_ERR(chan));

which can be simplified to:
------------------------------------------------
+                       if (device_property_match_string(dev,
"dma-names", name) >= 0)
+                               dev_warn(dev, "dma-names has '%s' but
request failed (%ld)\n",
+                                        name, PTR_ERR(chan));
-------------------------------------------------

I'll send a fix for this.

Best regards,
Phuc