On Mon, Nov 25, 2013 at 11:30 AM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > On 11/25/2013 12:28 PM, Dan Williams wrote: >> On Mon, Nov 25, 2013 at 11:00 AM, Stephen Warren <swarren@xxxxxxxxxxxxx> 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. > > OK great. Last two questions then: > > 1) Do you want me to revert the changes to acpi-dma.c, and simply handle > the return value conversion inside __dma_request_slave_channel(). Yeah, no need to spread the complexity further than necessary. > 2) What's the final call on the new API name? What do you think of _reason? I just read the existence of dma_request_slave_channel_or_err() as an implication that dma_request_slave_channel() may not fail. > Just let me know on both - the changes are simple. Thanks. Well thanks for hashing this back and forth, we can laugh about it over a drink at the next conference. -- 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
