linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 13/18] ARM: LPAE: ensure dma_addr_t is the same size as phys_addr_t
Date: Mon, 25 Oct 2010 12:32:09 +0100	[thread overview]
Message-ID: <1288006329.14756.13.camel@e102109-lin.cambridge.arm.com> (raw)
In-Reply-To: <201010251308.24063.arnd@arndb.de>

On Mon, 2010-10-25 at 12:08 +0100, Arnd Bergmann wrote:
> On Monday 25 October 2010, Catalin Marinas wrote:
> > From: Will Deacon <will.deacon@arm.com>
> >
> > Now that phys_addr_t can be 64-bit on ARM, we must ensure that dma_addr_t
> > is sufficiently large to hold physical addresses.
> >
> > This patch uses the types.h implementation in asm-generic to define the
> > dma_addr_t type as the same width as phys_addr_t.
> >
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> 
> This patch will become obsolete once the "unify dma_addr_t typedef"
> series from Fujita Tomonori is upstream, you will instead have to set
> CONFIG_ARCH_DMA_ADDR_T_64BIT.

Yes, I know this and it's on my list to fix once I update the patches to
2.6.37-rc1.

Thanks,

Catalin

  reply	other threads:[~2010-10-25 11:32 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-25  8:59 [RFC PATCH 00/18] ARM: Add support for the Large Physical Address Extensions Catalin Marinas
2010-10-25  8:59 ` [RFC PATCH 01/18] ARM: LPAE: Use PMD_(SHIFT|SIZE|MASK) instead of PGDIR_* Catalin Marinas
2010-10-25  8:59 ` [RFC PATCH 02/18] ARM: LPAE: Factor out 2-level page table definitions into separate files Catalin Marinas
2010-10-25  8:59 ` [RFC PATCH 03/18] ARM: LPAE: use u32 instead of unsigned long for 32-bit ptes Catalin Marinas
2010-10-25  8:59 ` [RFC PATCH 04/18] ARM: LPAE: Do not assume Linux PTEs are always at PTRS_PER_PTE offset Catalin Marinas
2010-10-25  9:00 ` [RFC PATCH 05/18] ARM: LPAE: Introduce L_PTE_NOEXEC and L_PTE_NOWRITE Catalin Marinas
2010-10-25  9:00 ` [RFC PATCH 06/18] ARM: LPAE: Introduce the 3-level page table format definitions Catalin Marinas
2010-10-25 11:15   ` Arnd Bergmann
2010-10-25 11:59     ` Catalin Marinas
2010-10-25 13:25       ` Arnd Bergmann
2010-10-25 16:18         ` Catalin Marinas
2010-10-25 18:25           ` Arnd Bergmann
2010-12-06  9:27             ` Christoffer Dall
2010-12-06 14:21               ` Arnd Bergmann
2010-10-25  9:00 ` [RFC PATCH 07/18] ARM: LPAE: Page table maintenance for the 3-level format Catalin Marinas
2010-10-25  9:00 ` [RFC PATCH 08/18] ARM: LPAE: MMU setup for the 3-level page table format Catalin Marinas
2010-10-25  9:00 ` [RFC PATCH 09/18] ARM: LPAE: Add fault handling support Catalin Marinas
2010-10-25 10:17   ` Kirill A. Shutemov
2010-10-25 10:35     ` Catalin Marinas
2010-10-25  9:00 ` [RFC PATCH 10/18] ARM: LPAE: Add context switching support Catalin Marinas
2010-10-25  9:00 ` [RFC PATCH 11/18] ARM: LPAE: Add SMP support for the 3-level page table format Catalin Marinas
2010-10-25  9:00 ` [RFC PATCH 12/18] ARM: LPAE: use phys_addr_t instead of unsigned long for physical addresses Catalin Marinas
2010-10-25  9:00 ` [RFC PATCH 13/18] ARM: LPAE: ensure dma_addr_t is the same size as phys_addr_t Catalin Marinas
2010-10-25 11:08   ` Arnd Bergmann
2010-10-25 11:32     ` Catalin Marinas [this message]
2010-10-25 12:01       ` FUJITA Tomonori
2010-10-25 12:31         ` Catalin Marinas
2010-10-25  9:00 ` [RFC PATCH 14/18] ARM: LPAE: mark memory banks with start > ULONG_MAX as highmem Catalin Marinas
2010-10-25  9:00 ` [RFC PATCH 15/18] ARM: LPAE: use phys_addr_t for physical start address in early_mem Catalin Marinas
2010-10-25  9:01 ` [RFC PATCH 16/18] ARM: LPAE: add support for ATAG_MEM64 Catalin Marinas
2010-10-25  9:01 ` [RFC PATCH 17/18] ARM: LPAE: define printk format for physical addresses and page table entries Catalin Marinas
2010-10-25 12:01   ` Kirill A. Shutemov
2010-10-25  9:01 ` [RFC PATCH 18/18] ARM: LPAE: Add the Kconfig entries Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1288006329.14756.13.camel@e102109-lin.cambridge.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).