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

From: [email-masked] (Stephen Warren)
Date: Wed, 20 Nov 2013 11:24:40 -0700

On 11/19/2013 05:38 PM, Dan Williams wrote:
> On Tue, Nov 19, 2013 at 4:09 PM, Stephen Warren <[email-masked]> wrote:
>> Deferred probe certainly isn't the only error that can be returned
>> though,
> 
> Of course, but do any of those other ones matter?  Certainly not if
> they've all been hidden behind a NULL return from
> dma_request_slave_channel().
> 
>> so I don't think "defer" in the name makes much sense. The
>> function as I wrote it returns a standard "error pointer" value.
>> Typically, callers would simply propagate *any* error code back to the
>> caller of probe() without even looking at it; it's the driver core that
>> checks for -EPROBE_DEFER vs. other error codes. In some cases, drivers
>> do check in order to avoid printing failure messages in the deferred
>> probe case, but again that's pretty standard, and not something specific
>> to this API.
> 
> Right, but the only reason to introduce this API is to propagate
> EPROBE_DEFER, right?  It also serves to document drivers that are
> prepared for / depend on deferred probing support.

Well, that's the reason I'm introducing the API, but it's not really
what the API actually does.

That said, in the interests of moving this forward, I'll go for your
suggested name dma_slave_request_channel_defer().

Do I need an ack from Vinod on the function name, or the patches?