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:	Tue, 2 Jun 2009 13:08:10 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	ian.campbell@...rix.com
Cc:	linux-kernel@...r.kernel.org, fujita.tomonori@....ntt.co.jp,
	mingo@...e.hu, jeremy@...p.org, tony.luck@...el.com,
	linux-ia64@...r.kernel.org
Subject: Re: [PATCH 01/11] ia64: introduce arch-specific dma-mapping
 interfaces

On Mon, 1 Jun 2009 16:32:53 +0100
Ian Campbell <ian.campbell@...rix.com> wrote:

> dma_map_range is intended to replace usage of both
> swiotlb_arch_range_needs_mapping and
> swiotlb_arch_address_needs_mapping as __weak functions as well as
> replacing is_buffer_dma_capable.
> 
> phys_to_dma and dma_to_phys are intended to replace
> swiotlb_phys_to_bus and swiotlb_bus_to_phys.  I choose to use dma
> rather than bus since a) it matches the parameters and b) avoids
> confusion on x86 with the existing (but deprecated) virt_to_bus
> function which relates to ISA device DMA.
> 
> Signed-off-by: Ian Campbell <ian.campbell@...rix.com>
> Cc: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
> Cc: Ingo Molnar <mingo@...e.hu>
> Cc: Jeremy Fitzhardinge <jeremy@...p.org>
> Cc: Tony Luck <tony.luck@...el.com>
> Cc: linux-ia64@...r.kernel.org
> ---
>  arch/ia64/include/asm/dma-mapping.h |   23 +++++++++++++++++++++++
>  1 files changed, 23 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/ia64/include/asm/dma-mapping.h b/arch/ia64/include/asm/dma-mapping.h
> index 36c0009..47d4107 100644
> --- a/arch/ia64/include/asm/dma-mapping.h
> +++ b/arch/ia64/include/asm/dma-mapping.h
> @@ -174,4 +174,27 @@ dma_cache_sync (struct device *dev, void *vaddr, size_t size,
>  
>  #define dma_is_consistent(d, h)	(1)	/* all we do is coherent memory... */
>  
> +static inline dma_addr_t phys_to_dma(struct device *hwdev, phys_addr_t paddr)
> +{
> +	return paddr;
> +}
> +
> +static inline phys_addr_t dma_to_phys(struct device *hwdev, dma_addr_t daddr)
> +{
> +	return daddr;
> +}
> +
> +static inline bool dma_map_range(struct device *dev, u64 mask,
> +				       phys_addr_t addr, size_t size,
> +				       dma_addr_t *dma_addr_p)
> +{
> +	dma_addr_t dma_addr = phys_to_dma(dev, addr);
> +
> +	if (dma_addr + size > mask)
> +		return false;
> +
> +	*dma_addr_p = dma_addr;
> +	return true;
> +}
> +

dma_map_range is a really confusing name. We have dma_map_single and
dma_map_sg, they are the DMA mapping API.

dma_map_range sounds like the DMA mapping API but it isn't. As I said,
Xen dom0 needs to implement something like xen_map_sg, xen_map_single,
etc, which uses some of swiotlb functions internally. Then we don't
need functions like the above.

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