Re: [PATCH v4] spi: qup: Add DMA capabilities

From: Lars-Peter Clausen
Date: Mon Mar 09 2015 - 05:12:54 EST

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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at