linux-kernel - Re: [PATCH] tile,mn10300: add device parameter to dma_cache

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 4 Apr 2011 20:50:41 +0100
From:	James Hogan <james@...anarts.com>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	dhowells@...hat.com, yasutake.koichi@...panasonic.com,
	cmetcalf@...era.com, akpm@...ux-foundation.org,
	james.hogan@...tec.com, konrad.wilk@...cle.com,
	lethal@...ux-sh.org, arnd@...db.de, linux-am33-list@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tile,mn10300: add device parameter to dma_cache_sync()

On Tue, Apr 05, 2011 at 02:50:40AM +0900, FUJITA Tomonori wrote:
> On Mon, 4 Apr 2011 16:21:47 +0100
> James Hogan <james@...anarts.com> wrote:
> 
> > From: James Hogan <james.hogan@...tec.com>
> > 
> > Note: I'm not in a position to compile test this patch, but I don't
> > foresee any problems.
> > 
> > Since v2.6.20 "Pass struct dev pointer to dma_cache_sync()"
> > (d3fa72e4556ec1f04e46a0d561d9e785ecaa173d), dma_cache_sync() takes a
> > struct dev pointer, but these appear to be missing from the tile and
> > mn10300 implementations, so add them.
> > 
> > Signed-off-by: James Hogan <james.hogan@...tec.com>
> > ---
> >  arch/mn10300/include/asm/dma-mapping.h |    2 +-
> >  arch/tile/include/asm/dma-mapping.h    |    3 ++-
> >  arch/tile/kernel/pci-dma.c             |    2 +-
> >  3 files changed, 4 insertions(+), 3 deletions(-)
> 
> Looks fine (I don't even compile it though).
> 
> btw, mn10300's dma_cache_sync looks wrong.
> 
> DMA-API says:
> 
> Do a partial sync of memory that was allocated by
> dma_alloc_noncoherent(), starting at virtual address vaddr and
> continuing on for size.  Again, you *must* observe the cache line
> boundaries when doing this.
> 
> looks like mn10300's dma_alloc_noncoherent() returns consistent
> memory. So dma_cache_sync should be a null function.

I noticed it explicitly says:
442 Note: where the platform can return consistent memory, it will
443 guarantee that the sync points become nops.

I presume dma_cache_sync() is the "sync points" it is referring to.

By the looks of it though the following architectures implement it but
define the noncoherent functions to the coherent versions so shouldn't
implement it (as far as I can tell):
 avr,blackfin,frv,microblaze,powerpc,sh,unicore32,x86,xtensia

and ia64 says it isn't required so just does a full memory barrier
instead (mb()).

Cheers
James
--
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/