linux-kernel - Re: [PATCH v4 4/6] dmaengine: Make DMA Engine menu visible for AVR32 users

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: <1214528379.32709.51.camel@dwillia2-linux.ch.intel.com>
Date:	Thu, 26 Jun 2008 17:59:39 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Haavard Skinnemoen <haavard.skinnemoen@...el.com>
Cc:	Adrian Bunk <bunk@...nel.org>,
	Pierre Ossman <drzeus-list@...eus.cx>,
	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org,
	kernel@...32linux.org,
	"Nelson, Shannon" <shannon.nelson@...el.com>,
	David Brownell <david-b@...bell.net>
Subject: Re: [PATCH v4 4/6] dmaengine: Make DMA Engine menu visible for
	AVR32 users


On Thu, 2008-06-26 at 07:46 -0700, Haavard Skinnemoen wrote:
> Adrian Bunk <bunk@...nel.org> wrote:
> > That discussion is mixing two different things I suggested besides other
> > things before the Kconfig file was added [1]:
> > - have DMA_ENGINE select'ed when a device gets enabled by the user,
> >   and not be an independent option
> > - switch to menuconfig and don't offer an empty kconfig menu
> >
> > There seems to be no disagreement about the former (which could
> > otherwise easily lead to users mistakenly enabling NET_DMA).
> >
> > The latter is more a cosmetical kconfig UI thing, and I already said
> > back then that it "could be dropped if it would become a problem" [2].
> 
> Ok, thanks for explaining. The menu does appear empty if I remove the
> architecture dependency without adding the driver...if that's a problem
> maybe we should do the HAVE_DMA_DEVICE thing...
> 
> > So if you want to remove the architecture dependency from the DMADEVICES
> > menu that's OK with me.
> 
> Ok, I'm gonna wait for Dan and others to respond. If it's fine with
> them, I'll post a patch removing the arch dependency.

I agree with removing the arch dependency, and I do not think we
necessarily need to add HAVE_DMA_ENGINE.  Taking an example from libata
the SATA_FSL driver depends on FSL_SOC but the menuconfig for ATA does
not.  We can use "depends on HAS_DMA" to make the menu disappear on
archs that will never have a dmaegine.  So I propose the following:

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6239c3d..e4dd006 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -4,13 +4,14 @@
 
 menuconfig DMADEVICES
 	bool "DMA Engine support"
-	depends on (PCI && X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX || PPC
-	depends on !HIGHMEM64G
+	depends on !HIGHMEM64G && HAS_DMA
 	help
 	  DMA engines can do asynchronous data transfers without
 	  involving the host CPU.  Currently, this framework can be
 	  used to offload memory copies in the network stack and
-	  RAID operations in the MD driver.
+	  RAID operations in the MD driver.  This menu only presents
+	  DMA Device drivers supported by the configured arch, it may
+	  be empty in some cases.
 
 if DMADEVICES
 
@@ -55,10 +56,12 @@ comment "DMA Clients"
 config NET_DMA
 	bool "Network: TCP receive copy offload"
 	depends on DMA_ENGINE && NET
+	default (INTEL_IOATDMA || FSL_DMA)
 	help
 	  This enables the use of DMA engines in the network stack to
 	  offload receive copy-to-user operations, freeing CPU cycles.
-	  Since this is the main user of the DMA engine, it should be enabled;
-	  say Y here.
+
+	  Say Y here if you enabled INTEL_IOATDMA or FSL_DMA, otherwise
+	  say N.
 
 endif



--
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/