[alsa-devel] [PATCH] ALSA: pcm_dmaengine: correct the error handler of dmaengine_prep_dma_cyclic

Lars-Peter Clausen lars at metafoo.de
Thu Dec 25 10:45:52 CET 2014


On 12/25/2014 10:08 AM, Barry Song wrote:
> 2014-12-25 17:02 GMT+08:00 Lars-Peter Clausen <lars at metafoo.de>:
>> On 12/25/2014 05:41 AM, Barry Song wrote:
>>>
>>> From: Barry Song <Baohua.Song at csr.com>
>>>
>>> preparing cyclic DMA description can fail either due to DMA desc list
>>> is full(-ENOMEM), or due to the coming DMA configuration is illegal or
>>> not supported by the acting DMA hardware(other ERR codes).
>>
>>
>> According to the API definition this returns either NULL or a valid
>> descriptor, so the behavior in pcm_dmaengine is correct. Maybe your
>> particular dmaengine driver as a incorrect implementation.
>
> i think it is something wrong. an functions returns pointer should return one of
> (1) right pointer
> (2) NULL
> (3) a wrong pointer from error CODES
>
> if for 2&3, we both return NULL, it actually means we are taking
> something wrong.
>
> this should be a generic rule as from clk and other subsystems. why
> does DMA want to do something special?

I think the dmaengine API simply predates the widespread use of ERR_PTR.

And it probably makes sense to update it to use ERR_PTR to have more 
meaningful error codes. But this needs to be done in a way that makes sure 
that all providers and all consumers agree on the same semantics. E.g. first 
update all consumers to handle ERR_PTR or NULL, then update all providers to 
return a ERR_PTR instead of NULL, then update all consumers to just handle 
ERR_PTR.

- Lars



More information about the Alsa-devel mailing list