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

Dan Williams dan.j.williams at intel.com
Mon Nov 25 13:42:52 EST 2013

On Mon, Nov 25, 2013 at 10:00 AM, Russell King - ARM Linux
<linux at arm.linux.org.uk> 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.

I was attempting to tap the brakes on the number of request_channel
apis in circulation.
... and now dma_request_slave_channel_reason

...but given we already have things like samsung_dmadev_request() in
the wild, tracking correct usage going forward will be an uphill
battle.  We can do this the other way round.  Introduce the new api
and delete the old one (after some time).


Can we make the new api not pass the 'defer' flag.  You mention it is
for compat reasons, but since there are no users I'm not seeing how
there can be compatibility concerns.  Can you elaborate?

More information about the linux-arm-kernel mailing list