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

Russell King - ARM Linux linux at arm.linux.org.uk
Mon Nov 25 14:09:36 EST 2013


On Mon, Nov 25, 2013 at 10:42:52AM -0800, Dan Williams wrote:
> 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.
> dma_request_channel
> dma_request_slave_channel
> dma_request_slave_channel_compat
> ... 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).

Yes, new and deprecate the old is the right way to do this.

> 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?

Yes, I agree.  I don't think there's a compatibility concern here - with
the old interface, a non-present resource would be indicated as "does not
exist".

If we convert any error pointer including the one representing
-EPROBE_DEFER to the "does not exist" representation, we're not changing
the behaviour.



More information about the linux-arm-kernel mailing list