[PATCH] dmaengine: shdma: fix a build failure on platforms with no DMA support
g.liakhovetski at gmx.de
Mon Jul 8 04:13:49 EDT 2013
On Fri, 5 Jul 2013, Vinod Koul wrote:
> On Wed, Jun 19, 2013 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
> > Hi Vinod
> > On Wed, 19 Jun 2013, Kevin Hilman wrote:
> > > On Thu, May 30, 2013 at 7:44 PM, Simon Horman <horms at verge.net.au> wrote:
> > >
> > > [...]
> > >
> > > > thanks for this. I will wait for a refresh (as we discussed earlier today).
> > > > Can I confirm that this is a fix for v3.10? If so, could ou note
> > > > that when you post your revised patch?
> > >
> > > Any progress on this patch?
> > >
> > > The SH-mobile defconfigs are still all failing in linux-next.
> > In
> > https://patchwork.kernel.org/patch/2640061/
> And you havent CC maintainers on this patch, so I dont have it!
Ouch, sorry, no idea how I managed not to CC you, my apologies!
> > I proposed a simple immediate fix for this problem. Arnd at the same time
> > developed an alternative solution:
> > https://patchwork.kernel.org/patch/2644121/
> > https://patchwork.kernel.org/patch/2644111/
> Reading these patches I agree with Arnd that client drivers should not depend on
> dma slave drivers. Existing issue need to be fixed
I'm not arguing against that. My point is the following: also Arnd's
patches have to deal with the fact, that the filter function has to be in
files, which will be compiled with SHDMA enabled or disabled in .config.
He solves this problem by adding #ifdef's to each .c file. Whereas I think
it's better to add just one such #ifdef to the header. The actual issue of
DMA client driver dependency on a specific dmaengine controller driver is
a different (though related) problem and should be addressed separately.
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
More information about the linux-arm-kernel