[v2,2/7] dmaengine: dw: Remove misleading is_private property

[Vinod Koul <vkoul@kernel.org>]

On 05-12-18, 18:28, Andy Shevchenko wrote:
> The commit a9ddb575d6d6
> 
>    ("dmaengine: dw_dmac: Enhance device tree support")
> 
> introduces is_private property in uncertain understanding what does it mean.
> 
> First of all, documentation defines DMA_PRIVATE capability as
> 
> Documentation/crypto/async-tx-api.txt:
>   The DMA_PRIVATE capability flag is used to tag dma devices that should not be
>   used by the general-purpose allocator. It can be set at initialization time
>   if it is known that a channel will always be private. Alternatively,
>   it is set when dma_request_channel() finds an unused "public" channel.
> 
>   A couple caveats to note when implementing a driver and consumer:
>   1/ Once a channel has been privately allocated it will no longer be
>      considered by the general-purpose allocator even after a call to
>      dma_release_channel().
>   2/ Since capabilities are specified at the device level a dma_device with
>      multiple channels will either have all channels public, or all channels
>      private.
> 
> Documentation/driver-api/dmaengine/provider.rst:
>   - DMA_PRIVATE
>     The devices only supports slave transfers, and as such isn't available
>     for async transfers.
> 
> The capability had been introduced by the commit 59b5ec21446b
> 
>   ("dmaengine: introduce dma_request_channel and private channels")
> 
> and some code didn't changed from that times ever.
> 
> Taking into consideration above and the fact that on all known platforms
> Synopsys DesignWare DMA engine is attached to serve slave transfers,
> the DMA_PRIVATE capability must be enabled for this device unconditionally.
> Otherwise, as rightfully noticed in drivers/dma/at_xdmac.c:
>   /*
>    * Without DMA_PRIVATE the driver is not able to allocate more than
>    * one channel, second allocation fails in private_candidate.
>    */
> because of of a caveats mentioned in above documentation excerpts.
> 
> So, remove conditional around DMA_PRIVATE followed by removal leftovers.
> 
> If someone wonders, DMA_PRIVATE can be not used if and only if the all channels
> of the DMA controller are supposed to serve memory-to-memory like operations.
> For example, EP93xx has two controllers, one of which can only perform
> memory-to-memory transfers
> 
> Note, this change doesn't affect dmatest to be able to test such controllers.
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (maintainer:SERIAL DRIVERS)
> Cc: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  Documentation/devicetree/bindings/dma/snps-dma.txt | 2 --
>  drivers/dma/dw/core.c                              | 4 +---
>  drivers/dma/dw/pci.c                               | 1 -
>  drivers/dma/dw/platform.c                          | 3 ---
>  drivers/tty/serial/8250/8250_lpss.c                | 1 -

Need ack from greg before applying this