The DMAengine API has a long standing race condition that is inherent to
the API itself. Calling dmaengine_terminate_all() is supposed to stop and
abort any pending or active transfers that have previously been submitted.
Unfortunately it is possible that this operation races against a currently
running (or with some drivers also scheduled) completion callback.

Since the API allows dmaengine_terminate_all() to be called from atomic
context as well as from within a completion callback it is not possible to
synchronize to the execution of the completion callback from within
dmaengine_terminate_all() itself.

This means that a user of the DMAengine API does not know when it is safe
to free resources used in the completion callback, which can result in a
use-after-free race condition.

This patch addresses the issue by introducing an explicit synchronization
primitive to the DMAengine API called dmaengine_synchronize().

The existing dmaengine_terminate_all() is deprecated in favor of
dmaengine_terminate_sync() and dmaengine_terminate_async(). The former
aborts all pending and active transfers and synchronizes to the current
context, meaning it will wait until all running completion callbacks have
finished. This means it is only possible to call this function from
non-atomic context. The later function does not synchronize, but can still
be used in atomic context or from within a complete callback. It has to be
followed up by dmaengine_synchronize() before a client can free the
resources used in a completion callback.

In addition to this the semantics of the device_terminate_all() callback
are slightly relaxed by this patch. It is now OK for a driver to only
schedule the termination of the active transfer, but does not necessarily
have to wait until the DMA controller has completely stopped. The driver
must ensure though that the controller has stopped and no longer accesses
any memory when the device_synchronize() callback returns.

This was in part done since most drivers do not pay attention to this
anyway at the moment and to emphasize that this needs to be done when the
device_synchronize() callback is implemented. But it also helps with
implementing support for devices where stopping the controller can require
operations that may sleep.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>

As discussed recently the meaning of DMA_CTRL_ACK is that a desc cannot be
reused by provider until the client acknowledges receipt, i.e. has has a
chance to establish any dependency chains. So update documentation
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>

Add documentation about acking the transfers, and their
reusability.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Document the new design of the pxa dma driver.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

- client.txt was moved by f36d2e67 (dmaengine: Move the current doc to a
  folder of its own)
- dmatmest.txt was moved by 935cdb56 (dmanegine: move dmatest.txt to
  dmaengine folder)
- provider.txt was added by c4d2ae96 (Documentation: dmaengine: Add a
  documentation for the dma controller API).

Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: dmaengine@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Signed-off-by: NHenrik Austad <henrik@austad.us>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

dma_slave_config is expected to be set for slave operations Only, not for
memcpy ones
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Now that we have splitted device_control and removed device_slave_caps in favor
of a few dma_device variables, update the documentation accordingly.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The dmaengine is neither trivial nor properly documented at the moment, which
means a lot of trial and error development, which is not that good for such a
central piece of the system.

Attempt at making such a documentation.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
[fixed some minor typos]
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Move the current client-side documentation to a subfolder to prepare the
introduction of a provider-side API documentation.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>