[PATCH 11/31] dma: add channel request API that supports deferred probe

[Dan Williams]

On Mon, Nov 25, 2013 at 11:30 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 11/25/2013 12:28 PM, Dan Williams wrote:
>> On Mon, Nov 25, 2013 at 11:00 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> I suppose an alternative would be to remove that flag, and have the loop
>>> in of_dma_request_slave_channel() initially ignore any unregistered DMA
>>> controllers, and still continue to look through the property for any
>>> alternative controller, and return a channel from one if it is found.
>>> Then, at the very end of the function, we could always return
>>> -EPROBE_DEFER if any unregistered DMA controllers were found, otherwise
>>> return -ENODEV. That would keep compatible behaviour, but it would mean
>>> that device probe order would/could influence which dmas entry provided
>>> the channel, since some entries might be ignored based simply on
>>> timing/ordering of DMA controller registration. Is that acceptable?
>>>
>>
>> Yes, I think this option makes the most sense, and is just as
>> susceptible to probe order as the current implementation.
>
> OK great. Last two questions then:
>
> 1) Do you want me to revert the changes to acpi-dma.c, and simply handle
> the return value conversion inside __dma_request_slave_channel().

Yeah, no need to spread the complexity further than necessary.

> 2) What's the final call on the new API name?

What do you think of _reason?  I just read the existence of
dma_request_slave_channel_or_err() as an implication that
dma_request_slave_channel() may not fail.

> Just let me know on both - the changes are simple. Thanks.

Well thanks for hashing this back and forth, we can laugh about it
over a drink at the next conference.