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

[Stephen Warren]

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().

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

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