linux-kernel - Re: [PATCH] DMAENGINE: add a slave buffer prep call

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:	Wed, 11 Aug 2010 21:02:04 +0200
From:	Linus Walleij <linus.ml.walleij@...il.com>
To:	Rabin Vincent <rabin@....in>
Cc:	Dan Williams <dan.j.williams@...el.com>,
	linux-kernel@...r.kernel.org, Sascha Hauer <s.hauer@...gutronix.de>
Subject: Re: [PATCH] DMAENGINE: add a slave buffer prep call

2010/8/11 Rabin Vincent <rabin@....in>:

> On Tue, Aug 10, 2010 at 11:46:06PM +0200, Linus Walleij wrote:
>> This makes it possible for engines to implement slave transfers
>> to be done to/from a simple kmalloc():ed memory buffer and not
>> just from scatterlists.
>
> Why is this needed?  Drivers can just pass in a single-entry scatterlist
> to the existing API to achieve the same functionality, and a couple of
> them already do so.

Because of the overhead, simply. Especially if you want to trigger
many jobs after each other. (This is necessary in device/slave-DMA
since every transaction may fail...) It's not just constructing the
sg-headers and freeing them again and again, it's also list traversals
here and there since the driver must assume it can be a linked sglist and
then two other list traversals for each
dma_map_sg()/dma_unmap_sg() pair and ... yeah that's basically
it.

And the number of extra code lines needed.

Then it's something conceptwise of creating a list that you know
is just always one element that is just not elegant, like taking a queue
numer and standing in queue when there is only one customer but
hey, maybe it's just me.

One way of achieving it for all present drivers is to wrap the passed
buffer in a single sglist and pass to the sglist function if the single
buffer call is not supported in the driver. Maybe it'd be better if I
coded up the patch like that so all driver can rely on this function
to be present?

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/