Re: [PATCH v1 4/7] ASoC: pxa: Replace dma_request_slave_channel() by dma_request_chan()

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, Sep 15, 2026 at 10:21:28AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] UAPI: -EPROBE_DEFER leaked to user-space open() via pxa2xx_pcm_open()
> --

[ ... ]

> > -	return snd_dmaengine_pcm_open(
> > -		substream, dma_request_slave_channel(snd_soc_rtd_to_cpu(rtd, 0)->dev,
> > -						     dma_params->chan_name));
> > +	chan = dma_request_chan(snd_soc_rtd_to_cpu(rtd, 0)->dev, dma_params->chan_name);
> > +	ret = PTR_ERR_OR_ZERO(chan);
> > +	if (ret)
> > +		return ret;
> 
> [Severity: Medium]
> Will this leak the kernel-internal -EPROBE_DEFER error code to user-space?
> 
> If dma_request_chan() fails because the DMA driver isn't loaded yet, it
> can return -EPROBE_DEFER.  Since pxa2xx_pcm_open() returns this directly, 
> the -EPROBE_DEFER error code would be passed up to snd_pcm_open() and 
> returned to the user-space application calling open() on the ALSA device.
> 
> In the old code, dma_request_slave_channel() returned NULL on failure,
> and snd_dmaengine_pcm_open() mapped that NULL to -ENXIO. Could we map the
> error here to a standard user-facing error like -ENXIO when 
> dma_request_chan() fails?

Sure, makes sense.

> > +	return snd_dmaengine_pcm_open(substream, chan);

-- 
With Best Regards,
Andy Shevchenko