linux-kernel - Re: [PATCH resent] dma: add the freescale-provided MultiChannel DMA driver

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: <20130221095233.GA8451@intel.com>
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/