(2010/06/17 13:22), H. Peter Anvin wrote: > On 06/16/2010 07:50 PM, Matthew Wilcox wrote: >> On Thu, Jun 17, 2010 at 10:30:06AM +0900, Kenji Kaneshige wrote: >>> Index: linux-2.6.34/arch/x86/mm/ioremap.c >>> =================================================================== >>> --- linux-2.6.34.orig/arch/x86/mm/ioremap.c 2010-06-15 >>> 04:43:00.978332015 +0900 >>> +++ linux-2.6.34/arch/x86/mm/ioremap.c 2010-06-15 05:32:59.291693007 >>> +0900 >>> @@ -62,8 +62,8 @@ >>> static void __iomem *__ioremap_caller(resource_size_t phys_addr, >>> unsigned long size, unsigned long prot_val, void *caller) >>> { >>> - unsigned long pfn, offset, vaddr; >>> - resource_size_t last_addr; >>> + unsigned long offset, vaddr; >>> + resource_size_t pfn, last_pfn, last_addr; >> >> I have a hard time understanding this change. pfn is always a physical >> address shifted by PAGE_SHIFT. So a 32-bit pfn supports up to 44-bit >> physical addresses. Are your addresses above 44-bits? >> > > I think they might be. Kenji? No. My addresses are in the 44-bits range (around fc000000000). So it is not required for my problem. This change assumes that phys_addr can be above 44-bits (up to 52-bits (and higher in the future?)). By the way, is there linux kernel limit regarding above 44-bits physical address in x86_32 PAE? For example, pfn above 32-bits is not supported? #ifdef CONFIG_X86_PAE /* 44=32+12, the limit we can fit into an unsigned long pfn */ #define __PHYSICAL_MASK_SHIFT 44 #define __VIRTUAL_MASK_SHIFT 32 If there is 44-bits physical address limit, I think it's better to use PHYSICAL_PAGE_MASK for masking physical address, instead of "(phys_addr >> PAGE_SHIFT) << PAGE_SHIFT)". The PHYSICAL_PAGE_MASK would become greater value when 44-bits physical address limit is eliminated. And maybe we need to change phys_addr_valid() returns error if physical address is above (1 << __PHYSICAL_MASK_SHIFT)? Thanks, Kenji Kaneshige -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html