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. Good old bike shedding... I only jumped in because I think changing it to dma_slave_request_chan() would indeed be confusing . -- 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
