linux-kernel - [PATCH] DMA: Correct invalid assumptions in the Kconfig text

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1193218705-16685-1-git-send-email-hskinnemoen@atmel.com>
Date:	Wed, 24 Oct 2007 11:38:25 +0200
From:	Haavard Skinnemoen <hskinnemoen@...el.com>
To:	Shannon Nelson <shannon.nelson@...el.com>
Cc:	linux-kernel@...r.kernel.org, David Brownell <david-b@...bell.net>,
	kernel@...32linux.org, linux-arm-kernel@...ts.arm.linux.org.uk,
	Haavard Skinnemoen <hskinnemoen@...el.com>
Subject: [PATCH] DMA: Correct invalid assumptions in the Kconfig text

This patch corrects what I hope are invalid assumptions about the DMA
engine layer: Not only Intel(R) hardware can do DMA, and DMA can be
used for other things than memcpy and RAID offloading.

At the same time, make the DMA Engine menu visible again on AVR32. I'm
currently working on a driver for a DMA controller that can do
mem-to-mem transfers (which is supported by the framework) as well as
device-to-mem and mem-to-device transfers (not currently supported.)

Signed-off-by: Haavard Skinnemoen <hskinnemoen@...el.com>
---
Don't get me wrong; I think Intel deserves lots of respect for
creating this framework. But this is also why I got a bit disappointed
when I discovered that it seems to be less generic than I initially
hoped.

DMA controllers, which may support plain memcpy acceleration in
addition to more traditional "slave DMA", are very common in SoC
devices, and I think Linux needs a common framework for it. The
existing DMA Engine framework seems to come pretty close already, but
I think it needs more input from the embedded crowd before it can be
completely usable on a large number of embedded systems.

I'm not going to suggest any changes to the actual framework for
2.6.24, but I think the _intention_ of the framework needs to be
clarified.

Haavard

 drivers/dma/Kconfig |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 9c91b0f..62a9fe5 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -3,11 +3,13 @@
 #

 menuconfig DMADEVICES
-	bool "DMA Offload Engine support"
-	depends on (PCI && X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX
+	bool "DMA Engine support"
+	depends on (PCI && X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX || AVR32
 	help
-	  Intel(R) offload engines enable offloading memory copies in the
-	  network stack and RAID operations in the MD driver.
+	  DMA engines can do asynchronous data transfers without
+	  involving the host CPU. This can be used to offload memory
+	  copies in the network stack and RAID operations in the MD
+	  driver.

 if DMADEVICES

-- 
1.5.3.4

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/