On Wed, Jul 31, 2013 at 12:46:42AM +0800, Stephen Warren wrote: > On 07/29/2013 09:31 PM, Richard Zhao wrote: > > On Sat, Jul 27, 2013 at 03:39:15AM +0800, Stephen Warren wrote: > >> On 07/23/2013 10:09 PM, Richard Zhao wrote: > >>> - driver: remove use of nvidia,dma-request-selector > >>> use dma_request_slave_channel to request channel > >>> - update binding doc > >> > >> This patch needs to be amended so that the DMA channel is looked up > >> during probe() rather than open(), to guarantee that deferred probe > >> works. It's possible to hold off probe, but not possible AFAIK to hold > >> off opening the port. > > > > How about avoid return -EPROBE_DEFER at open() time? It can be in > > another patch. > > I don't really understand what you mean. -EPROBE_DEFER is something that > only makes sense for probe() to return (or functions used by probe()). > It doesn't make sense to return it anywhere else, since probe deferral > is something that can only happen for probe(). What I meant is, it might not worth to move request channel to probe only because we need to check error and return -EPROBE_DEFER. dma_request_slave_channel is better to be called as late as possible to make better dynamic use of dma channels. Actually, I searched the kernel code, most drivers don't return EPROBE_DEFER when dma_request_slave_channel failed. dma_request_slave_channel can fail in many cases, and dma device not probed is only one case. Thanks Richard -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html