dmaengine: move HIGHMEM64G restriction to ASYNC_TX_DMA

On HIGHMEM64G systems dma_addr_t is known to be larger than (void *)
which precludes async_xor from performing dma address conversions by
reusing the input parameter address list.  However, other parts of the
dmaengine infrastructure do not suffer this constraint, so the
HIGHMEM64G restriction can be down-levelled.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>

2 files changed, 3 insertions, 3 deletions

diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c
index 95fe2c8d6c51..90dd3f8bd283 100644
--- a/crypto/async_tx/async_xor.c
+++ b/crypto/async_tx/async_xor.c
@@ -300,7 +300,7 @@ EXPORT_SYMBOL_GPL(async_xor_zero_sum);
 
 static int __init async_xor_init(void)
 {
-        #ifdef CONFIG_DMA_ENGINE
+        #ifdef CONFIG_ASYNC_TX_DMA
         /* To conserve stack space the input src_list (array of page pointers)
          * is reused to hold the array of dma addresses passed to the driver.
          * This conversion is only possible when dma_addr_t is less than the
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 3b3c01b6f1ee..babf214a509b 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -4,7 +4,7 @@
 
 menuconfig DMADEVICES
         bool "DMA Engine support"
-        depends on !HIGHMEM64G && HAS_DMA
+        depends on HAS_DMA
         help
           DMA engines can do asynchronous data transfers without
           involving the host CPU.  Currently, this framework can be
@@ -100,7 +100,7 @@ config NET_DMA
 
 config ASYNC_TX_DMA
         bool "Async_tx: Offload support for the async_tx api"
-        depends on DMA_ENGINE
+        depends on DMA_ENGINE && !HIGHMEM64G
         help
           This allows the async_tx api to take advantage of offload engines for
           memcpy, memset, xor, and raid6 p+q operations.  If your platform has