linux-kernel - Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

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] [day] [month] [year] [list]

Message-ID: <20130206074508.GB22064@arwen.pp.htv.fi>
Date:	Wed, 6 Feb 2013 09:45:08 +0200
From:	Felipe Balbi <balbi@...com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Tony Lindgren <tony@...mide.com>, Felipe Balbi <balbi@...com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Sergei Shtylyov <sshtylyov@...sta.com>,
	Matt Porter <mporter@...com>,
	Linux DaVinci Kernel List 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	Chris Ball <cjb@...top.org>,
	"Cousson, Benoit" <b-cousson@...com>,
	Linux Documentation List <linux-doc@...r.kernel.org>,
	Devicetree Discuss <devicetree-discuss@...ts.ozlabs.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Linux MMC List <linux-mmc@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Vinod Koul <vinod.koul@...el.com>,
	Rob Landley <rob@...dley.net>, Dan Williams <djbw@...com>,
	Linux SPI Devel List 
	<spi-devel-general@...ts.sourceforge.net>,
	Linux OMAP List <linux-omap@...r.kernel.org>,
	Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to
 arm/common

On Tue, Feb 05, 2013 at 10:26:30PM +0000, Arnd Bergmann wrote:
> On Tuesday 05 February 2013, Tony Lindgren wrote:
> > * Felipe Balbi <balbi@...com> [130204 07:46]:
> > > 
> > > Current DMA abstraction is quite poor, for example there's no way to
> > > compile support for multiple DMA engines. Code also makes certain, IMO
> > > unnecessary, assumptions about the underlying DMA engine (abstraction is
> > > poor, as said above but it we could follow MUSB's programming guide when
> > > it comes to programming DMA transfers).
> > > 
> > > Considering all of the above, it's far better to use DMA engine and get
> > > rid of all the mess.
> > 
> > How about just disable MUSB DMA support if ARCH_MULTIPLATFORM for now?
> > That way MUSB can be fixed up first to support ARCH_MULTIPLATFORM
> > using PIO while sorting out the DMA related issues.
> 
> Sounds ok to me. Someone still needs to do the work to make the non-DMA
> variants of MUSB coexist in one kernel, but as we discussed erlier, that
> should be much simpler.

Yeah, I'm cooking some patches to at least make it buildable. Dropping
unnecessary dependencies and marking da8xx and davinci as depending on
BROKEN seems to be the easiest way; those two glues hasn't seen a real
patch since 2010 or so.

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)