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

Dan Williams dan.j.williams at intel.com
Tue Nov 19 19:38:29 EST 2013


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.

Good old bike shedding... I only jumped in because I think changing it
to dma_slave_request_chan() would indeed be confusing .



More information about the linux-arm-kernel mailing list