linux-kernel - Re: [PATCH] asm-generic: add dma-mapping-linear.h

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: <200906041442.53170.arnd@arndb.de>
Date:	Thu, 4 Jun 2009 14:42:52 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Russell King <rmk+lkml@....linux.org.uk>
Cc:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH] asm-generic: add dma-mapping-linear.h

On Thursday 04 June 2009, Russell King wrote:
> And here we go promoting dma-mask-is-not-a-mask-but-a-limit (which I
> brought up in the KS thread on linux-arch.)
> 
> It's fine if your DMA-able memory starts at physical address 0 and ends
> somewhere else, but this is no longer the case with embedded platforms.
> As pointed out in the other thread, there are platforms which have two
> separate banks of memory, the one at the lower physical address is not
> DMA capable.

The dma-mapping-linear.h only cares about the platforms that have a
linear contigous mapping between DMA and phys addresses. Other
platforms will have to do something more fancy in their dma mapping
implementation.

The device sets a mask (really a limit) of the address ranges it can
handle. Basically every user in the kernel currently passes DMA_BIT_MASK()
limit into {dma,pci}_set_mask,  and I am not aware of any driver
that needs something more fancy. If you know one, please tell us.

The DMA-capable addresses of the platform are a completely different
issue and these should not be confused. Some architecture solve this
by bus-specific mapping operations, which sounds like what you would
need here as well. The bus is the only instance in the system that knows
how the device-visible DMA space maps into the physical memory space,
and it needs to be the instance checking the mask.

The only place where the mask is really used later is dma_alloc_coherent,
which can also be bus specific, and should know how to interpret the
mask.

	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/