linux-kernel - Re: [PATCH 02/11] x86: introduce arch-specific dma-mapping interface

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: <20090602130424I.fujita.tomonori@lab.ntt.co.jp>
Date:	Tue, 2 Jun 2009 13:08:09 +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,
	jeremy@...p.org, okir@...e.de, gregkh@...e.de, x86@...nel.org
Subject: Re: [PATCH 02/11] x86: introduce arch-specific dma-mapping
 interface

On Mon, 1 Jun 2009 16:32:54 +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: Jeremy Fitzhardinge <jeremy@...p.org>
> Cc: Olaf Kirch <okir@...e.de>
> Cc: Greg KH <gregkh@...e.de>
> Cc: x86@...nel.org
> ---
>  arch/x86/include/asm/dma-mapping.h |    7 +++++++
>  arch/x86/kernel/pci-dma.c          |   26 ++++++++++++++++++++++++++
>  2 files changed, 33 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/include/asm/dma-mapping.h b/arch/x86/include/asm/dma-mapping.h
> index 916cbb6..be8cb22 100644
> --- a/arch/x86/include/asm/dma-mapping.h
> +++ b/arch/x86/include/asm/dma-mapping.h
> @@ -47,6 +47,9 @@ static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
>  #define dma_free_noncoherent(d, s, v, h) dma_free_coherent(d, s, v, h)
>  #define dma_is_consistent(d, h)	(1)
>  
> +extern dma_addr_t phys_to_dma(struct device *hwdev, phys_addr_t paddr);
> +extern phys_addr_t dma_to_phys(struct device *hwdev, dma_addr_t daddr);
> +
>  extern int dma_supported(struct device *hwdev, u64 mask);
>  extern int dma_set_mask(struct device *dev, u64 mask);
>  
> @@ -309,4 +312,8 @@ static inline void dma_free_coherent(struct device *dev, size_t size,
>  		ops->free_coherent(dev, size, vaddr, bus);
>  }
>  
> +extern bool dma_map_range(struct device *dev, u64 mask,
> +			  phys_addr_t addr, size_t size,
> +			  dma_addr_t *dma_addr_p);
> +
>  #endif
> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> index 745579b..f4c1b03 100644
> --- a/arch/x86/kernel/pci-dma.c
> +++ b/arch/x86/kernel/pci-dma.c
> @@ -59,6 +59,32 @@ int dma_set_mask(struct device *dev, u64 mask)
>  }
>  EXPORT_SYMBOL(dma_set_mask);
>  
> +dma_addr_t phys_to_dma(struct device *hwdev, phys_addr_t paddr)
> +{
> +	return paddr;
> +}
> +EXPORT_SYMBOL_GPL(phys_to_dma);
> +
> +phys_addr_t dma_to_phys(struct device *hwdev, dma_addr_t daddr)
> +{
> +	return daddr;
> +}
> +EXPORT_SYMBOL_GPL(dma_to_phys);
> +
> +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;
> +}
> +EXPORT_SYMBOL_GPL(dma_map_range);
> +

Why can't the above functions live in arch/include/asm/dma-mapping.h,
where they should live?
--
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/