From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCH 11/31] dma: add channel request API that supports deferred probe Date: Wed, 20 Nov 2013 11:24:40 -0700 Message-ID: <528CFE68.6060908@wwwdotorg.org> References: <1384548866-13141-1-git-send-email-swarren@wwwdotorg.org> <1384548866-13141-12-git-send-email-swarren@wwwdotorg.org> <1384766276.14845.155.camel@smile> <528A5170.3090809@wwwdotorg.org> <1384862421.14845.222.camel@smile> <528B9CAE.3040600@wwwdotorg.org> <528BFDD0.3090503@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Dan Williams Cc: Andy Shevchenko , Stephen Warren , "Koul, Vinod" , "pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org" , "dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: linux-tegra@vger.kernel.org On 11/19/2013 05:38 PM, Dan Williams wrote: > On Tue, Nov 19, 2013 at 4:09 PM, Stephen Warren 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? From mboxrd@z Thu Jan 1 00:00:00 1970 From: swarren@wwwdotorg.org (Stephen Warren) Date: Wed, 20 Nov 2013 11:24:40 -0700 Subject: [PATCH 11/31] dma: add channel request API that supports deferred probe In-Reply-To: References: <1384548866-13141-1-git-send-email-swarren@wwwdotorg.org> <1384548866-13141-12-git-send-email-swarren@wwwdotorg.org> <1384766276.14845.155.camel@smile> <528A5170.3090809@wwwdotorg.org> <1384862421.14845.222.camel@smile> <528B9CAE.3040600@wwwdotorg.org> <528BFDD0.3090503@wwwdotorg.org> Message-ID: <528CFE68.6060908@wwwdotorg.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 11/19/2013 05:38 PM, Dan Williams wrote: > On Tue, Nov 19, 2013 at 4:09 PM, Stephen Warren 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?