linux-kernel - RE: [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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BAE9DCEF64577A439B3A37F36F9B691C0349A780@orsmsx418.amr.corp.intel.com>
Date:	Wed, 24 Oct 2007 08:11:23 -0700
From:	"Nelson, Shannon" <shannon.nelson@...el.com>
To:	"Haavard Skinnemoen" <hskinnemoen@...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>
Subject: RE: [PATCH] DMA: Correct invalid assumptions in the Kconfig text

>From: Haavard Skinnemoen [mailto: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
>

Acked-by: Shannon Nelson <shannon.nelson@...el.com>
-
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/