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: <CACRpkdY7ApBc-gbSdf+=7PLtKSMvzYuBi7RNnVgi=vjcd-KvhQ@mail.gmail.com>
Date:	Fri, 16 Mar 2012 15:11:52 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Guennadi Liakhovetski <g.liakhovetski@....de>
Cc:	Vinod Koul <vinod.koul@...el.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org,
	Jassi Brar <jassisinghbrar@...il.com>,
	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 Fri, Mar 16, 2012 at 12:09 PM, Guennadi Liakhovetski
<g.liakhovetski@....de> wrote:

> And the least important question: who and when will implement the core
> support for this?

I'm trying to call the kernel HR department to hire a consultant for me but they
just put me on the phone queue all the time, I don't know what I might be
doing wrong ... :-)

If the question is whether we need more people writing complicated core
patches for the dmaengine I think the answer is "yes"?

> 1. the client issues a dma_request_channel() with _just_ a capability mask
> and a filter and its argument as parameters - _nothing_ about channel
> restrictions.
>
> 2. you propose to eliminate a filter - the core has no way to know, which
> channel to pick up...

Nah, thinking about it...

Eliminate the external filter, make it internal. We already have the
problem that these filter functions need to be passed around too much
in platform data e.g. so we need to do away with it.

The filter functions seem to come from the DMA drivers
themselves mostly. (Help me with the complete picture here...)
For example:

amba-pl08x.c:bool pl08x_filter_id(struct dma_chan *chan, void *chan_id)
coh901318.c:bool coh901318_filter_id(struct dma_chan *chan, void *chan_id)
pl330.c:bool pl330_filter(struct dma_chan *chan, void *param)
sirf-dma.c:bool sirfsoc_dma_filter_id(struct dma_chan *chan, void *chan_id)
ste_dma40.c:bool stedma40_filter(struct dma_chan *chan, void *data)

So delete the typedef for dma_filter_fn remove these filters from
external header files.

And stop that thing from being passed around and into
struct dma_device so the dmaengine core can still filter or process
channels, but nothing on the outside need to know about it. That way
we can centralize it to drivers/dma and not spread it out throughout
the kernel.

> 3. the wrapper, proposed by Russell, now calls dmaengine_slave_config(),
> which fails, because that's a wrong channel (hope I get this right this
> time - configuration has nothing to do with selection:-))

Oh I was not thinking of relying on config to sort out channels.

I was thinking of internalizing the dma_filter_fn and make it an
(optional, maybe?) part of dmaengine.

> 4. that's it, if you start again - the dmaengine core will enumerate the
> same channels again and propose the same unsuitable channel to you -
> there's no way to continue to the next channel / device.
>
> What am I missing? How is the mapping going to be used, if you eliminate
> the filter function?

As above, I guess factoring away the filter functions would be
the first real hard problem.

Thanks,
Linus Walleij
--
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/