linux-kernel - Re: [PATCH 3/4] dma: sh: provide a migration path for slave drivers to stop using .private

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: <20120712040018.GB11440@linux-sh.org>
Date:	Thu, 12 Jul 2012 13:00:19 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Magnus Damm <magnus.damm@...il.com>
Cc:	Guennadi Liakhovetski <g.liakhovetski@....de>,
	Vinod Koul <vinod.koul@...el.com>, linux-sh@...r.kernel.org,
	linux-mmc@...r.kernel.org, Chris Ball <cjb@...top.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] dma: sh: provide a migration path for slave drivers
 to stop using .private

On Thu, Jul 12, 2012 at 06:55:32AM +0900, Magnus Damm wrote:
> Hi Guennadi,
> 
> [CC Paul]
> 
> On Thu, Jul 5, 2012 at 1:17 AM, Guennadi Liakhovetski
> <g.liakhovetski@....de> wrote:
> > This patch extends the sh dmaengine driver to support the preferred channel
> > selection and configuration method, instead of using the "private" field
> > from struct dma_chan. We add a standard filter function to be used by
> > slave drivers instead of implementing their own ones, and add support for
> > the DMA_SLAVE_CONFIG control operation, which must accompany the new
> > channel selection method. We still support the legacy .private channel
> > allocation method to cater for a smooth driver migration.
> >
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@....de>
> > ---
> 
> Thanks for your efforts on this. Something that caught my eye in this
> patch is this portion:
> 
> +bool shdma_chan_filter(struct dma_chan *chan, void *arg);
> 
> If we would use this function in our DMA Engine slave drivers (MMCIF,
> SDHI, SCIF, FSI, SIU and so on) then wouldn't we add a strict
> dependency on this symbol provided by this particular DMA Engine
> driver implementation for the DMAC hardware (that your patch
> modifies)?
> 
> And what do we do if we want to use the same DMA Engine slave driver
> with a different DMA Engine driver implementation?
> 
> From my point of view, there must be some better way to not have such
> tight dependencies between the DMA Engine slave consumer and the DMA
> Engine driver. Not sure what that looks like though. This symbol
> dependency is pretty far from great IMO.
> 
I vaguely recall this coming up before, and it wasn't acceptable then
either.

We will by no means be adding driver-specific hooks in to other drivers
that really couldn't care less what the underlying DMA engine driving
them is.

We already have CPUs with different DMA engines that can be used by the
same drivers. As I said the last time, this needs to be fixed in the
dmaengine framework, period.
--
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/