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, 27 Jan 2010 14:19:44 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	adharmap@...eaurora.org
Cc:	fujita.tomonori@....ntt.co.jp, benh@...nel.crashing.org,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	dwalker@...eaurora.org, arnd@...db.de, akpm@...ux-foundation.org,
	mingo@...e.hu, joerg.roedel@....com, maciej.sosnowski@...el.com,
	dan.j.williams@...el.com, beckyb@...nel.crashing.org,
	yanghy@...fujitsu.com, linux-arch@...r.kernel.org,
	adharmap@...cinc.com
Subject: Re: [RFC PATCH] dma: Add barrierless dma mapping/unmapping api

On Tue, 26 Jan 2010 12:11:34 -0800
Abhijeet Dharmapurikar <adharmap@...eaurora.org> wrote:

> FUJITA Tomonori wrote:
> > On Tue, 26 Jan 2010 15:30:10 +1100
> > Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:
> > 
> >> On Mon, 2010-01-25 at 18:35 -0800, adharmap@...eaurora.org wrote:
> >>> From: Abhijeet Dharmapurikar <adharmap@...cinc.com>
> >>>
>   >
> >> There are people nowadays putting AXI bridges and the whole ARM
> >> paraphernalia of IP cores behind them on PowerPC cores for example and I
> >> can see that happening with x86 as well.
> >>
> >> In your case, I believe your are fixing the wrong problem anyways. The
> >> right approach would be instead to put all your buffer into an sglist
> >> and use dma_map/unmap_sg().
> > 
> > Agreed again. That's exactly what I suggested before:
> > 
> > http://marc.info/?l=linux-kernel&m=126294076917753&w=2
> 
> I somehow missed your post, my apologies. Agreed that dma_map/unmap_sg 
> would be the correct api to use here, however they still call the 
> dmac_.*_range to map buffers.

Hmm, sounds like arm's implementation issue. dma_map_sg API doesn't
require such. dma_map_sg API gives what you want, do a sync only after
mapping the last buffer.


> I could change those calls to do a barrier 
>   only after mapping the last buffer. This would be much more cleaner 
> than introducing a .*_nobarrier API.
--
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/

Powered by blists - more mailing lists