linux-kernel - Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request

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:	Wed, 7 Mar 2012 14:26:34 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Guennadi Liakhovetski <g.liakhovetski@....de>
Cc:	Vinod Koul <vinod.koul@...el.com>, linux-kernel@...r.kernel.org,
	'Jassi Brar' <jassisinghbrar@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Magnus Damm <magnus.damm@...il.com>,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH/RFC] dmaengine: add a slave parameter to
	__dma_request_channel()

On Wed, Mar 07, 2012 at 02:49:25PM +0100, Guennadi Liakhovetski wrote:
> On Wed, 7 Mar 2012, Russell King - ARM Linux wrote:
> > What
> > would be useful is to have a helper function along these lines:
> > 
> > struct dma_chan *dma_request_channel_config(mask, fn, data, config)
> > {
> > 	struct dma_chan *c = dma_request_channel(mask, fn, data);
> > 
> > 	if (c) {
> > 		if (dmaengine_slave_config(c, config)) {
> > 			dma_release_channel(c);
> > 			c = NULL;
> > 		}
> > 	}
> > 	return c;
> > }
> 
> Hm, yeah... That seems like an over-complication to me: to "just" allocae 
> a channel you cann dma_request_channel(), which scans your devices and 
> channels on them, calls your filter, calls the DMA controller driver's 
> allocation method, only to eventually call dmaengine_slave_config() and 
> see it fail, after which you release the channel and start anew...

The point is _not_ that this uses dmaengine_slave_config() to find a
channel at all.  As I already said, there's nothing in dma_slave_config
which _could_ be used to decide whether a channel is suitable or not.

So to try to filter on the slave configuration is a pure red herring.
None of the DMA controllers I have access to (whether they be working
or not) could make any kind of decision about whether a particular
channel is suitable for the peripheral by looking at the dma_slave_config
structure - it's very much the case that the decision would be that
'any channel will do', which in reality it won't because there's other
information required to make the decision about which virtual channel
should be used.  Specifically, the request signal information.

Even more specifically, the request signal information may not be _just_
the request signal on the DMA controller but also incorporate an
external MUX like on the Realview boards (which pl08x handles itself.)

I do not see any milage in trying to select a channel based on "I want
a DMA engine to access register X, width Y, burst size Z."  As far as
I can see, the common situation is that there's nothing in that set of
information which would be useful to chose a specific channel on a
DMA engine.
--
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/