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]

Message-ID: <20110921101857.GA29782@flint.arm.linux.org.uk>
Date:	Wed, 21 Sep 2011 11:18:57 +0100
From:	Russell King <rmk@....linux.org.uk>
To:	Jassi Brar <jaswinder.singh@...aro.org>
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 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.

> > Same as few ields in xt_template would be for peripheral case..
>
> No properly written client would ever pass 'invalid' values for
> xt_template members.
> But _every_ properly written Mem->Mem client would have to
> ask for DMA_TO/FROM_DEVICE, following what you suggest.

Which is definitely a good thing.

> Btw, even if we wanted, Memcpy couldn't be represented by
> either DMA_TO_DEVICE or  DMA_FROM_DEVICE, because
> both Src and Dst increments here.

memcpy(dst,src,len) would require the source to be mapped DMA_TO_DEVICE
and the destination mapped DMA_FROM_DEVICE via the DMA API.

Look, the DMA_TO_DEVICE/FROM_DEVICE are completely separate properties
from "do we increment the source" "do we increment the destination"
properties.

There are existing client drivers in the kernel which already use M->P
DMA with non-incrementing source memory addresses (SPI transfers where
the transmit path has to be loaded with dummy data) and P->M DMA with
non-incrementing destination memory addresses (SPI discarding RX data.)

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.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
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/