linux-kernel - Re: [RFC v2 2/5] dmaengine: Add slave DMA interface

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 31 Jan 2008 04:51:03 -0800
From:	David Brownell <david-b@...bell.net>
To:	Paul Mundt <lethal@...ux-sh.org>
Cc:	Haavard Skinnemoen <hskinnemoen@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	linux-kernel@...r.kernel.org,
	Shannon Nelson <shannon.nelson@...el.com>,
	kernel@...32linux.org, Francis Moreau <francis.moro@...il.com>,
	"Vladimir A. Barinov" <vbarinov@...mvista.com>,
	Pierre Ossman <drzeus-list@...eus.cx>
Subject: Re: [RFC v2 2/5] dmaengine: Add slave DMA interface

On Thursday 31 January 2008, Paul Mundt wrote:
> On Thu, Jan 31, 2008 at 12:27:24AM -0800, David Brownell wrote:
> > On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
> > > So basically, you're asking for maximum flexibility with minimum
> > > overhead.
> >
> > That's always a goal, but that's not what I said.  I was pointing out
> > one scenario I ran into ... where starting with the simple solution
> > ran into product issues which were unfixable without using some of the
> > more advanced (and nonportable!!) hardware mechanisms.
> >
> >
> > > I agree that should be the ultimate goal, but wouldn't it 
> > > be better to start with something more basic?
> > 
> > Where you start is often NOT where you end up!  You should make sure
> > that a wants-to-be-generic slave interface can accomodate a variety of
> > non-basic mechanisms, without getting bloated.  :)
> 
> I agree with Haavard here. The original dmaengine code was sparse at best
> and for a very specific type of workload, evolving that in to something
> that can be used by far more people with minimal pain is a good first
> step. Trying to overengineer it from the beginning to accomodate fringe
> controllers that already have an established API 

Which is not at all what I suggested.  When you want to set up a
straw man to argue against, please don't involve me!

First steps are after all followed by second steps, and often
by third steps.  It's not "overengineering" to recognize when
those steps necessarily have a direction.

In this case, that direction is "working on more hardware", so
evaluating the interface proposal against several types of
hardware is a good way to review it.  The hardware I referenced
doesn't seem "fringe" to me; it's used on more Linux systems
and by more users than the Synopsys design.  And I've seen some
of the same issues on other DMA controllers:  priority, options
for synchronization (e.g. after DMAREQ is signaled), and more.

In that vein, doesn't SuperH have DMA controllers to fit into this
proposed interface?  I don't know about such "fringe" hardware
myself, but it'd be good to know if this proposal is sufficient
for the needs of drivers there.

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