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

[Stephen Warren]

On 11/20/2013 12:15 PM, Dan Williams wrote:
> On Wed, Nov 20, 2013 at 10:24 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 11/19/2013 05:38 PM, Dan Williams wrote:
>>> On Tue, Nov 19, 2013 at 4:09 PM, Stephen Warren <swarren at wwwdotorg.org> 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.
>>
> 
> True, this is quite a bit of back and forth for something that will be
> temporary.  How bad would it be to short-circuit this discussion and
> go straight to converting dma_request_slave_channel().  Leave
> dma_request_channel() as is and just convert the 20 or so users of
> dma_request_slave_channel() over?

I had thought about that, but there are drivers that use
dma_request_slave_channel(), but fall back to dma_request_channel() if
that fails. I think there were other cases where the two APIs were
mixed. Drivers would then have a value that sometimes IS_ERR() or is
valid, and other times ==NULL or is valid. So, the values would have to
be checked using IS_ERR_OR_NULL() which I believe is now deprecated  -
certainly Russell will shout at me if I start introducing more usage! So
that means converting dma_request_channel()'s return value too, and that
is a /lot/ more to convert. I suppose an alternative might be to have
the individual affected drivers convert a NULL return from
dma_request_channel() to an ERR value, but for some reason I forget now,
even that looked problematic.