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]
Date:	Thu, 21 Feb 2013 15:22:33 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Philippe De Muyter <phdm@...qel.be>
Cc:	linux-kernel@...r.kernel.org, Greg Ungerer <gerg@...pgear.com>,
	Stany MARCEL <smarcel@...tenovation.fr>,
	Dan Williams <djbw@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH resent] dma: add the freescale-provided MultiChannel
 DMA driver

On Thu, Feb 21, 2013 at 09:29:47AM +0100, Philippe De Muyter wrote:
> > 2. If you are not using dmaengine APIs then drivers/dma/ is not a place for you.
> 
> What would be the place then for a multi-architecture dma driver.  Freescale often
> reuses the same blocks for its m68k (coldfire), powerpc and arm (iMX) product
> lines.  A dma driver with many similarities is already under the arch/powerpc
> subtree.  I would like to avoid that, because it clearly hurts reusability.
So the question is will there be any more users of the driver other than the
ethernet one? If No then it should live with ethernet driver.

DMAengine framework should be used where you have a system dma controller used
by different subsystems.
> 
> > 3. While glancing at the code, I dont see why you cant use dmaengine APIs?
> lack of need (the sole current user of this dma driver is a FEC ethernet driver
> which uses the current interface), time and expertise.  but any help is welcome.
> 
> > 4. lastly, am blown off by your own implementation of memcpy, WHY? Kernel is
> > smarter than you!
> I agree, but don't shoot the messenger.  I am not the original author, this is
> freescale code.  I only ensured that it compiles and works with current kernels,
> and suppressed many checkpatch warnings.
Okay but you could have removed these before sending it. Hopefully next version
will have these kind of stuff taken care of :)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ