linux-kernel - Re: [PATCHv3] DMAEngine: Define interleaved transfer request api

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, 21 Sep 2011 20:51:16 +0530
From:	Jassi Brar <jaswinder.singh@...aro.org>
To:	Russell King <rmk@....linux.org.uk>
Cc:	Vinod Koul <vinod.koul@...el.com>, dan.j.williams@...el.com,
	linux-kernel@...r.kernel.org, 21cnbao@...il.com
Subject: Re: [PATCHv3] DMAEngine: Define interleaved transfer request api

On 21 September 2011 15:48, Russell King <rmk@....linux.org.uk> wrote:
> On Wed, Sep 21, 2011 at 01:01:24PM +0530, Jassi Brar wrote:
>> Of course!
>> It doesn't make any sense for a mem->mem client asking
>> for DMA_FROM_DEVICE when it wanted MemSet.
>
> Yes it does.  For memset, you _are_ DMAing data from the DMA device to
> memory.  The fact that the data is constant is merely incidental (and
> a private property of the DMA controller.)
>
> Also, this memory *has* to be mapped via the DMA API to ensure coherency,
> and it *has* to be mapped using DMA_FROM_DEVICE.  Otherwise you won't see
> the data until effects such as cache eviction have happened (even then
> you may find your nicely memset'd data is overwritten by dirty cache
> lines.)
>
> So, to say that M2M transfers don't have DMA_FROM_DEVICE/TO_DEVICE
> properties shows a lack of appreciation for what is actually going on
> at the hardware level.
I don't discount that. I just think memory map/unmap'ing should not be
any business of the dmac driver. It should be handled by either client
or by some common part of dmaengine api.
Infact I never really asked 'why' the dmac driver needs to know the
direction, rather I only tried to explain 'how' it can find out.

Anyways, I am ok if this new api too must support map/unmap'ing of
buffers on behalf of the client.

> So, there's _absolutely_ no way that any sane API can ever infer the
> DMA direction from the source/destination increment specifications.
> Ignore this at your peril (and you'll find that people will botch
> around your new API.)
Yes. But having a 'enum dma_data_direction' flag wouldn't make it
future-proof either.

Seems I would have to define something like :-
enum xfer_direction {
	MEM_TO_MEM,
	MEM_TO_DEV,
	DEV_TO_MEM,
	DEV_TO_DEV,
 };

And replace every 'enum dma_data_direction' in the dmaengine api
with 'enum xfer_direction'

Thanks.
--
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/