Right, it would be best to first merge patch "[PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel()" and then port this library on top of it, then private will not be used any more.

> Any slave config should be extracted from dma_lsave_config only... Do> you anything more than which is provided there??

I don't think the dmaengine_slave_config() API is very well suitable for our situation. The problem is, that on sh-mobile not all DMA controllers support all functions. E.g., sh7372 has two dedicated USB DMA controllers, that otherwise are fully compatible with other DMA controllers on that platforms. If a client requests a channel for a USB slave and gets back a channel on one of other DMAC instances, issuing dmaengine_slave_config() with a USB configuration, obviously, will not work. Similarly, if a client would try to allocate a non-USB channel on a USB controller. So, it is best to be able to decide at dma_request_channel() time, whether and from which controller this slave channel request can be satisfied.

Again, that's also something, that should be handled by the proposed patch. With it any additional information, required to configure the controller and / or the channel for the slave operation is passed already to the allocation routine. Then, hopefully, no additional handshaking would be needed.

Well, right, some drivers might implement more. So, our choice is either to preemptively prepare code to handle those, or wait until such drivers surface and wish to use this library, then we can extend it to handle those too.

Ok, let me explain a bit more the intensions of this library. You're right, it is indeed doing more than just descriptor list manipulations. But the list handling is the most complex part of the library, which is why I advertised it as a library for aiding in that.

As a matter of fact, this library appeared when an attempt has been made to extend the shdma library to support the SUDMAC controller:

As you can see there, the SUDMAC hardware is completely incompatible with the original sh-mobile DMAC engines, but the SUDMAC code was able to reuse the driver to 99% by only replacing hardware-specific parts. So, instead of doing that I proposed to extract the generic code to a library and only provide hardware-specific bits to handle DMAC and SUDMAC. Since descriptor management is the largest and most complex part of the library, that's also how I described it.

I think, it would be good to preserve the library design at large as is, maybe updating its description to more precisely explain what it does, port it on top of the slave-parameter in channel allocation patch, maybe add some cosmetic improvements. If you think as it stands it is not generic enough, because it takes too much freedom away from individual drivers, we can make a step back and make it sh-mobile specific to be used only by shdma and sudmac, and then see, whether any other drivers will want to use it and how it will then have to be adjusted.