On 03/08/2015 01:20 PM, Andy Shevchenko wrote:
On Sun, Mar 8, 2015 at 1:21 PM, Lars-Peter Clausen <lars@xxxxxxxxxx> wrote:
On 03/07/2015 08:43 PM, Andy Shevchenko wrote:
On Sat, Mar 7, 2015 at 1:21 PM, Mark Brown <broonie@xxxxxxxxxx> wrote:
Applied, but why is there no devm_dma_request_slave_channel_reason()?
I suppose the answer would be "we have a lot of slightly different
cases and we have to get rid of current mess with legacy API calls".
The most problematic stuff now inside DMA slave subsystem is so called
"filter function". It's a main impediment right now as I understand.
dma_request_slave_channel_reason() is the sane API though and does not use
the filter functions. Adding a devm version of it seems reasonable.
It would be dma_request_slave_channel() in the first place, but legacy
stuff didn't allow to do that, so here we are. I wouldn't like the
idea of creating devm_dma_* before we will have stable function names
without legacy involving.
At some point when all callers dma_request_slave_channel() have been updated
to use dma_request_slave_channel_reason(), the later might be renamed to the
former. I don't see the problem with having to do the same for a
devm_dma_request_slave_channel_reason().
- Lars
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
