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.1203071906040.19595@axis700.grange>
Date:	Wed, 7 Mar 2012 19:21:51 +0100 (CET)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
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()

Thanks for a detailed explanation!

On Wed, 7 Mar 2012, Russell King - ARM Linux wrote:

> On Wed, Mar 07, 2012 at 04:44:12PM +0100, Guennadi Liakhovetski wrote:
> > So, the question remains: which way should we go? If we don't come up with 
> > a generic solution, I'd be inclined to just do something as silly as
> > 
> > arch/arm/mach-shmobile/board-*.c
> > 
> > static const struct device *group1_dma_dev[] = {
> > 	&dma0.device,
> > 	&dma1.device,
> > };
> > 
> > static const struct device *group2_dma_dev[] = {
> > 	&dma2.device,
> > 	&dma3.device,
> > };
> > 
> > static struct my_platform_data = {
> > 	.dma_dev_list = group1_dma_dev,
> > 	.dma_dev_list_num = ARRAY_SIZE(group1_dma_dev),
> > };
> > 
> > drivers/.../sh_*.c
> > 
> > static bool filter(struct dma_chan *chan, void *arg)
> > {
> > 	struct device *dev = chan->dev->device.parent;
> > 	struct my_platform_data *pdata = arg;
> > 
> > 	for (i = 0; i < pdata->dma_dev_list_num; i++)
> > 		if (pdata->dma_dev_list[i] == dev)
> > 			return true;
> > 
> > 	return false;
> > }
> > 
> > even though I find it silly to have to do this on every platform and in 
> > every driver.
> 
> Why are you thinking that the filter function implementation has to be
> provided by the peripheral driver?  That's just wrong and broken.

Again: because I don't like adding private APIs to a generic one.

> Think about it - how does the peripheral driver know what kind of dma
> channel its filter function has been passed - to give an example, if
> you built into your kernel support for the PL08x DMA engine, and lets
> say you had PL08x DMA engine hardware, how would your filter function
> decide whether it was one of your per-device channels or whether it
> was a PL08x DMA engine channel?

Sorry, there must be a confusion here: I was not proposing the above 
implementation for all hardware types, I don't have a good overview of all 
possible DMA engine scenarious and, fortunately, I don't have to implement 
anything that generic:-)

Even though I did write above "arch/arm/mach-shmobile/board-*.c" it 
probably wasn't clear enough: I was only talking about the shdma DMA 
engine driver and its clients. And so far on all sh-mobile hardware, that 
I'm aware of, we haven't been mixing DMA engine types on the same 
hardware. This is going to change soon, as soon as we get USBHS?-DMAC 
support in the kernel, but even then, those controllers will not be 
interchangeable: only USBHS devices will be served by USBHS-DMAC 
controllers, the rest can be served by any other controller. So, matching 
on a DMA controller device would perfectly suffice.

Of course, client drivers have no access to those device objects, that's 
why those lists have to be provided to them by the platform code.

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/