From mboxrd@z Thu Jan 1 00:00:00 1970 From: dan.j.williams@intel.com (Dan Williams) Date: Mon, 25 Nov 2013 11:28:39 -0800 Subject: [PATCH 11/31] dma: add channel request API that supports deferred probe In-Reply-To: <52939E67.6040300@wwwdotorg.org> References: <528D28A1.2050307@wwwdotorg.org> <528E4F55.9070204@wwwdotorg.org> <528F95A9.2050305@wwwdotorg.org> <528F9DF9.6080706@wwwdotorg.org> <20131123003442.GH16735@n2100.arm.linux.org.uk> <5293883A.8050808@wwwdotorg.org> <20131125180000.GR16735@n2100.arm.linux.org.uk> <52939E67.6040300@wwwdotorg.org> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Nov 25, 2013 at 11:00 AM, Stephen Warren wrote: > I suppose an alternative would be to remove that flag, and have the loop > in of_dma_request_slave_channel() initially ignore any unregistered DMA > controllers, and still continue to look through the property for any > alternative controller, and return a channel from one if it is found. > Then, at the very end of the function, we could always return > -EPROBE_DEFER if any unregistered DMA controllers were found, otherwise > return -ENODEV. That would keep compatible behaviour, but it would mean > that device probe order would/could influence which dmas entry provided > the channel, since some entries might be ignored based simply on > timing/ordering of DMA controller registration. Is that acceptable? > Yes, I think this option makes the most sense, and is just as susceptible to probe order as the current implementation.