On Fri, 3 Sep 2010 09:51:31 +0900 FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > There are about twenty architectures have the own dma_addr_t typedef > because include/asm-generic/types.h can't be perfect (some of them can > use it though): > > #ifndef dma_addr_t > #ifdef CONFIG_PHYS_ADDR_T_64BIT > typedef u64 dma_addr_t; > #else > typedef u32 dma_addr_t; > #endif /* CONFIG_PHYS_ADDR_T_64BIT */ > #endif /* dma_addr_t */ > > Another problem is that there is a way to determine if dma_addr_t is > 64-bit. We see hopeless tricks like the following: > > #if (defined(__i386__) && defined(CONFIG_HIGHMEM64G)) || defined(__x86_64__) || defined (__ia64__) || defined(__alpha__) || defined(__mips64__) || (defined(__mips__) && defined(CONFIG_HIGHMEM) && defined(CONFIG_64BIT_PHYS_ADDR)) > > This clean up the mess with introducing CONFIG_ARCH_DMA_ADDR_T_64BIT > define (like CONFIG_ARCH_PHYS_ADDR_T_64BIT). > > If architecture needs 64bit dma_addr_t, it must enable > CONFIG_ARCH_DMA_ADDR_T_64BIT. > > The summary are: > > - always 64bit > -- alpha > -- ia64 > -- tile > > - conditionally 64bit > -- x86 > -- mips > -- powerpc > -- s390 > > - always 32bit > -- arm > -- avr32 > -- cris > -- frv > -- h8300 > -- m32r > -- m68k > -- mn10300 > -- parisc > -- xtensa > -- sparc > -- blackfin > -- microblaze > -- score > -- sh Am I correct in believing that we can merge the first seven patches into arch trees at any time and, once they are all merged, patch 8/8 can then go into mainline? -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
