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:	Fri, 16 Mar 2012 11:16:14 +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 10:36 AM, Guennadi Liakhovetski
<g.liakhovetski@....de> wrote:

> Ok, let me try to summarise, what this would mean for sh-mobile:
>
> 1. this proposal introduces a new special case: with or without a mapping,
> that will have to be handled in affected client and DMA controller
> drivers. E.g., on sh-mobile some devices might on some systems use
> channels from "general purpose" DMA controllers (no mapping), on other
> systems it will be a dedicated controller (fixed mapping).
>
> 2. this will break, if we get more than 1 "general purpose" type with
> different supported client sets. So, we develop a new API with a
> pre-programmed limitation.

I fail to see why this would not be solved by a one-to-many mapping?

Flag for each device which channels it may use in a mapping
table in platform data or device tree, I don't see the problem.

You don't even have to specify that on a per-channel basis if
you can come up with something more clever in the mapping
table, such as "this device can use any channel on this DMAC,
and channels 1-7 on that DMAC" - no problem?

> 3. this will mean a substantial driver and platform code modification.
> Nothing super-complex, but still some.

Big deal. Refactoring is fun... ;-)

> 4. we'll need a 3-stage channel allocation / configuration: request,
> filter, config.

In my world: channel request with *NO* filter function.

Filter functions are part of the problem. So we refactor these
away as part of this change. That's the whole point...

The core gathers information from the platform and the
DMAC driver(s) to build up the constraints necessary to
hand out workling channels to each device that request
one.

And Russell IIRC already suggested a request-and-config
channel inline for the simple cases, and if you still need to
explicitly runtime-reconfigure then that's for a good
reason.

> Whereas with my configuration-parameter proposal it's just
> one stage: allocate-and-configure.

For one specific hardware, yes. For DMAengine at large
and the majority of the drivers, no.

Yours,
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/