Andy Shevchenko wrote at Thursday, October 8, 2020 9:06 AM:
> During internal review of one patch I have been puzzled with the following code
> and Pierre suggested to ask mailing list for help.
>
> My main concern is what was the idea behind? Does it mean we support optional
> DMA in such case? If now, why not to return an error code directly?
>
> ---8<---8<---8<---
>
> > Why ASoC core has the following code in the first place:
> >
> > 387 chan = dma_request_chan(dev, name);
> > 388 if (IS_ERR(chan)) {
> > 389 if (PTR_ERR(chan) == -EPROBE_DEFER)
> > 390 return -EPROBE_DEFER;
> > 391 pcm->chan[i] = NULL;
> > 392 } else {
> > 393 pcm->chan[i] = chan;
> > 394 }
> >
> > (note lines 389-391).
> > If PIO fallback is not okay, why not to return an error there?
>
> no idea, the code has been this way since 2013
> (5eda87b890f867b098e5566b5543642851e8b9c3)
It's been there a bit longer, in fact since the file was created:
commit 28c4468b00a1e55e08cc20117de968f7c6275441
Author: Lars-Peter Clausen <lars@xxxxxxxxxx>
Date: Mon Apr 15 19:19:50 2013 +0200
ASoC: Add a generic dmaengine_pcm driver
+ pcm->chan[i] = of_dma_request_slave_channel(dev->of_node,
+ dmaengine_pcm_dma_channel_names[i]);
The commit you mentioned above simply prevents the code from taking the "no DMA
available" path if deferred probe occurs.
> It's worth asking the question on the mailing list, I don't know if this is a
> bug or a feature.
This does seem like a bug, but there are a few places in the code which explicitly check
for a NULL chan or dma_dev (derived from chan) object, so it seems deliberate.
