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:	Fri, 22 May 2009 17:05:53 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	jgarzik@...ox.com, hancockrwd@...il.com, htejun@...il.com,
	alan@...rguk.ukuu.org.uk, flar@...andria.com,
	schmitz@...phys.uni-duesseldorf.de, linux-kernel@...r.kernel.org,
	linux-ide@...r.kernel.org, takata@...ux-m32r.org,
	geert@...ux-m68k.org, linux-m68k@...r.kernel.org,
	ysato@...rs.sourceforge.jp, grundler@...gle.com
Subject: Re: [PATCH] asm-generic: add a dma-mapping.h file

On Friday 22 May 2009, FUJITA Tomonori wrote:
> I'm not sure. And only mips internally uses CONFIG_DMA_COHERENT.
> 
> The reason why many architectures need architecture-specific
> alloc_coherent() is not about coherent or not.
> 
> I like a new helper header file having only generic functions without
> any ifdef.

Ok, fair enough. Fixing dma_alloc_coherent to handle
coherent_dma_mask and debug_dma correctly would also
make it even bigger, and it was already doing more than
you'd want from a commonly used inline function.
It may be useful to put it into kernel/dma-coherent.c
under an #ifdef, but I'll leave this one alone for now.

I'll leave dma_alloc_coherent and dma_free_coherent
as extern declarations then, and leave out the
simple dma_coherent_dev() and dma_cache_sync() that
all architectures would need to override.

dma_get_cache_alignment() is still less generic than
the other functions, as this is still architecture
specific. Should I leave that out as well then?

One more idea I had was to rename all the functions in
this file from dma_* to dma_linear_*. This would mean
that all architectures using it would still need to
do something like #define dma_map_sg dma_linear_map_sg
for each function they want to use but can easily chose
to provide their own ones for those they need different.

It might also help architectures that work with dma_ops,
which could then define their own
struct dma_ops dma_ops_linear = {
	.map_single = dma_linear_map_single,
	.map_sg = dma_linear_map_sg,
	...
};

Would you prefer me to do it this way, or just keep the
standard function names as in the current patch?

	Arnd <><
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ