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

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

On 11/25/2013 11:00 AM, Russell King - ARM Linux wrote:
> On Mon, Nov 25, 2013 at 09:45:18AM -0800, Dan Williams wrote:
>> Regardless of whether the driver was dma_request_channel as a
>> fallback, it will currently use NULL to indicate an allocation
>> failure.
> 
> At the moment, dma_request_slave_channel()'s return values are valid
> pointer or NULL.  I'd suggest as that's how it's been established,
> that function is left alone - changing the return values in this kind
> of invisible way is Really Bad(tm) because you can't check that it's
> right in any future users - unless you're prepared to review every
> single new user of this function for the next few years or more.
> 
> Instead, leaving it as is and introducing a new function name with
> the different return error method is the right way to do this.

Uggh. So here's the history of my patch series:

a) Started modifying dma_request_slave_channel() since there are very
few users right now, and it seemed simple to convert them all.

b) Found that some places mixed dma_request_slave_channel() and
dma_request_channel(). Converting dma_request_channel()'s return value
in the same way seemed prohibitive since it's much more widely used and
has been around for longer.

c) Rewrote patch to introduce a new function instead, since that didn't
require converting any existing drivers.

d) Received review feedback that I really should convert the existing
function's return code.

e) Started work on that using the return-value-conversion idea from Dan,
which allowed the two "return value styles" to co-exist easily, since I
figured that would be accepted.

Now you're telling me I should do what I already did in the patch, but
Dan is telling me to do the opposite:-(

How do we resolve this? Is there an option both you and Dan can accept?