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: <CACRpkdY4y6Dj+G0zNoeY5DGWW1CRXez4pVCju2SXc=9oNyzdGw@mail.gmail.com>
Date:	Thu, 8 Mar 2012 12:46:32 +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 Thu, Mar 8, 2012 at 11:16 AM, Guennadi Liakhovetski
<g.liakhovetski@....de> wrote:

>(...) our case can be handled _very_ easily:
>
> 1. a client requests a channel of a specific type
> 2. one of channels of that type, residing on one of compatible
>   controllers, is allocated, configured and handed in to the client
>
> That's it. No filtering, no post-allocation configuration - at least so
> far. And penalising such a simple case by forcing it to use virtual
> channels and filter through some unnatural mappings doesn't seem very
> productive to me.

But you do realize that this increases the complexity of the
dmaengine and means more maintenance burden for the
subsystem maintainer that will after this have to think in two
different sematic ways about channel retrieveal - yeah this one
passes that as parameter and this one has a config struct
provided, then this one use a filter function still - etc.

That is, of course, unless you convert all the existing DMA
engines to do it the same way, then it's redesigning proper.

In that case I am much more positive to the change, even
if it doesn't take us all the way to the new channel mappings
we want to have.

You haven't stated whether you will go in and rewrite the other
drivers to use this scheme or whether you will just add this one
kludge to handle this one DMA controller, then just update
all others to ignore the parameter. (You'd obviously have to
do that to get this to even compile...)

So the *proper* way to refactor to using this scheme would
be to introduce this new scheme *and* remove the filter
function from all the other drivers and DMA engine at large,
so it's not needed anymore. Which means a bit of refactoring.

Currently drivers have to pass a filter function from
platform data to filter out relevant channels, and with
the new style (this patch plus removing all filter functions)
it will be passing something else instead. That's all
fine, and actually an improvement, because passing around
a filter function is not as good as passing some struct
with data.

So does RFC patch mean you will fix this up for everyone
or does it mean something else?

If you're not also planning to get rid of the filter functions
for all other drivers I don't see this going anywhere right
now. It is not beneficial for dmaengine, the only benefit
is one more kludgy driver to maintain.

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/