On 11/19/2013 05:38 PM, Dan Williams wrote: > On Tue, Nov 19, 2013 at 4:09 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> 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. That said, in the interests of moving this forward, I'll go for your suggested name dma_slave_request_channel_defer(). Do I need an ack from Vinod on the function name, or the patches? -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
