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]

Message-ID: <Pine.LNX.4.64.1203191524200.11516@axis700.grange>
Date:	Mon, 19 Mar 2012 15:45:45 +0100 (CET)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	Vinod Koul <vinod.koul@...el.com>
cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	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 Mon, 19 Mar 2012, Vinod Koul wrote:

> On Mon, 2012-03-19 at 15:09 +0100, Guennadi Liakhovetski wrote:
> > YES! This is exactly what I am talking about! We need an additional 
> > parameter to dma_request_channel(). Whereas in the discussion, that you 
> > pointed me to, it still had the same 3 parameters, as now. (Maybe this has 
> > already been decided upon before - to add an additional parameter, not 
> > sure anymore, this thread has become too long and too slow... My apologies 
> > in this case) So, this can be a device pointer or some specialised slave 
> > ID. Device pointer is nice, I agree. And the next change, that I'd like to 
> > request is pass this parameter further on to DMA device driver's 
> > .device_alloc_chan_resources() method. 
> Sorry my bad. I confused your request for additional parameter as
> request for adding slave_config etc stuff into request API.
> 
> Yes this API would need to be modified for telling dmaengine about
> client. Now Given that this is more slave stuff, I have leaning to
> adding a slave specific request api, something like
> dmaengine_request_slave_channel() which is used for our purpose while
> keeping the original API intact for async_tx usages.
> 
> Btw why should .device_alloc_chan_resources() need this, I so no reason,
> unless we are working around some other issue.

The reason is the following: with the proposed modifications to the 
existing API we want to achieve:

1. client requests a channel
	dmaengine_request_slave_channel(dev)
2. the core looks through platform-specific mapping tables and finds a 
   suitable channel
3. the core calls device driver's .device_alloc_chan_resources() method 
   for that channel
4. the client uses
	dmaengine_slave_config(chan, config)
   to configure the channel

Now, that last channel configuration can have two aspects: (1) static: 
routing, multiplexing, peripheral address. This needs to be set only once 
per each such channel allocation to a specific client, (2) (potentially) 
dynamic: any burst sizes etc. We can pass both these configuration types 
together to the DMA device driver at step 4. For that the slave would have 
to embed struct dma_slave_config into another hardware-specific type with 
additional routing parameters. Otherwise we could pass static 
configuration, supplied by the platform, from the client to the DMA device 
driver already at step 1. This way we would avoid having to embed struct 
dma_slave_config and pass it around even if the driver doesn't actually 
use it. In some cases step 4 would be then dropped completely. But I can 
live with either solution.

Another reason is, that in the future it can happen, that we get further 
restrictions on channel selection, that will not fit into the standard 
mapping scheme. In this case, having access to slave's identification, the 
DMA device driver will have another chance to check, whether the proposed 
channel is indeed suitable.

BTW, if we only pass a device pointer and return to the client channels 
one-by-one, how will the client know, which channel it just has got back - 
Tx or Rx? Will it have to try to configure it for each role and see, which 
one succeeds?...

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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/