On Monday 30 March 2009, Geert Uytterhoeven wrote: > On Mon, Mar 30, 2009 at 15:58, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > +/* > > + * int-ll64 is used on all 32 bit architectures and on x86-64, > > + * so use it as a reasonable default. > > + */ > > +#include <asm-generic/int-ll64.h> > > + > > Most 64-bit archs have been migrated to ll64 by now. > Alpha, ia64, and mips64 are the remaining exceptions. Right, the comment is stale. > > +/* > > + * DMA addresses may be larger than pointers, but not smaller. > > + * Do not define the dma64_addr_t type, which never really > > + * worked. > > + */ > > +#if defined(CONFIG_64BIT) || defined(CONFIG_PHYS_64BIT) > > +typedef u64 dma_addr_t; > > +#else > > +typedef u32 dma_addr_t; > > +#endif /* 64 bit DMA pointer */ > > Is there any specific reason why dma_addr_t is in <asm/types.h>, while > phys_addr_t is in > <linux/types.h>? dma_addr_t is a big mess that was traditionally defined per architecture, in lots of wrong ways, including the misconception of dma64_addr_t. Sparc64 still uses a 32 bit dma_addr_t, possibly because it always uses an IOMMU (?). It can save some space in scatterlists, but might come back to bite us if someone tries to build a sparc64 system with actual 64-bit DMA. phys_addr_t is a new definition that was added last August (after I did my patch) by Jeremy Fitzhardinge and is for DMA purposes. > Furthermore, CONFIG_PHYS_64BIT is used on PPC only. Probably it should be > replaced by CONFIG_PHYS_ADDR_T_64BIT, which is always set if CONFIG_64BIT, > so the #ifdef above becomes even simpler? Yes, they could be consolidated now, which would make the default dma_addr_t the same as phys_addr_t, with the possible exception of sparc64. Arnd <>< -- 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