Re: [PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-17 Thread Toshi Kani
On Mon, 2013-06-17 at 16:36 -0700, Yinghai Lu wrote: > On Mon, Jun 17, 2013 at 4:19 PM, Toshi Kani wrote: > > On Fri, 2013-06-14 at 17:56 -0700, Yinghai Lu wrote: > >> Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not > >> be used anymore. > > > > Can you describe why

Re: [PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-17 Thread Yinghai Lu
On Mon, Jun 17, 2013 at 4:19 PM, Toshi Kani wrote: > On Fri, 2013-06-14 at 17:56 -0700, Yinghai Lu wrote: >> Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not >> be used anymore. > > Can you describe why max_low_pfn_mapped should not be used? Is this to > allow moving the code

Re: [PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-17 Thread Toshi Kani
On Fri, 2013-06-14 at 17:56 -0700, Yinghai Lu wrote: > Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not > be used anymore. Can you describe why max_low_pfn_mapped should not be used? Is this to allow moving the code of acpi_initrd_override() up before init_mem_mapping() in a

Re: [Part1 PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-17 Thread Tejun Heo
On Mon, Jun 17, 2013 at 2:13 PM, Yinghai Lu wrote: >> No bigge, but why (1ULL << 32) - 1? Shouldn't it be just 1ULL << 32? >> memblock deals with [@start, @end) areas, right? > > that is for 32bit, when phys_addr_t is 32bit, in that case > (1ULL<<32) cast to 32bit would be 0. Right, it'd work

Re: [Part1 PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-17 Thread Yinghai Lu
On Mon, Jun 17, 2013 at 2:04 PM, Tejun Heo wrote: > Hello, > > On Thu, Jun 13, 2013 at 09:02:50PM +0800, Tang Chen wrote: >> From: Yinghai Lu >> >> Now we have pfn_mapped[] array, and max_low_pfn_mapped should not >> be used anymore. Users should use pfn_mapped[] or just >> 1UL<<(32-PAGE_SHIFT)

Re: [Part1 PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-17 Thread Tejun Heo
Hello, On Thu, Jun 13, 2013 at 09:02:50PM +0800, Tang Chen wrote: > From: Yinghai Lu > > Now we have pfn_mapped[] array, and max_low_pfn_mapped should not > be used anymore. Users should use pfn_mapped[] or just > 1UL<<(32-PAGE_SHIFT) instead. > > The only user of max_low_pfn_mapped is

Re: [Part1 PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-17 Thread Tejun Heo
Hello, On Thu, Jun 13, 2013 at 09:02:50PM +0800, Tang Chen wrote: From: Yinghai Lu ying...@kernel.org Now we have pfn_mapped[] array, and max_low_pfn_mapped should not be used anymore. Users should use pfn_mapped[] or just 1UL(32-PAGE_SHIFT) instead. The only user of max_low_pfn_mapped

Re: [Part1 PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-17 Thread Yinghai Lu
On Mon, Jun 17, 2013 at 2:04 PM, Tejun Heo t...@kernel.org wrote: Hello, On Thu, Jun 13, 2013 at 09:02:50PM +0800, Tang Chen wrote: From: Yinghai Lu ying...@kernel.org Now we have pfn_mapped[] array, and max_low_pfn_mapped should not be used anymore. Users should use pfn_mapped[] or just

Re: [Part1 PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-17 Thread Tejun Heo
On Mon, Jun 17, 2013 at 2:13 PM, Yinghai Lu ying...@kernel.org wrote: No bigge, but why (1ULL 32) - 1? Shouldn't it be just 1ULL 32? memblock deals with [@start, @end) areas, right? that is for 32bit, when phys_addr_t is 32bit, in that case (1ULL32) cast to 32bit would be 0. Right, it'd

Re: [PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-17 Thread Toshi Kani
On Fri, 2013-06-14 at 17:56 -0700, Yinghai Lu wrote: Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not be used anymore. Can you describe why max_low_pfn_mapped should not be used? Is this to allow moving the code of acpi_initrd_override() up before init_mem_mapping() in a

Re: [PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-17 Thread Yinghai Lu
On Mon, Jun 17, 2013 at 4:19 PM, Toshi Kani toshi.k...@hp.com wrote: On Fri, 2013-06-14 at 17:56 -0700, Yinghai Lu wrote: Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not be used anymore. Can you describe why max_low_pfn_mapped should not be used? Is this to allow moving

Re: [PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-17 Thread Toshi Kani
On Mon, 2013-06-17 at 16:36 -0700, Yinghai Lu wrote: On Mon, Jun 17, 2013 at 4:19 PM, Toshi Kani toshi.k...@hp.com wrote: On Fri, 2013-06-14 at 17:56 -0700, Yinghai Lu wrote: Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not be used anymore. Can you describe why

[PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-14 Thread Yinghai Lu
Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not be used anymore. User should use arch_pfn_mapped or just 1UL<<(32-PAGE_SHIFT) instead. Only user is ACPI_INITRD_TABLE_OVERRIDE, and it should not use that, as later accessing is using early_ioremap(). We could change to use

[PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-14 Thread Yinghai Lu
Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not be used anymore. User should use arch_pfn_mapped or just 1UL(32-PAGE_SHIFT) instead. Only user is ACPI_INITRD_TABLE_OVERRIDE, and it should not use that, as later accessing is using early_ioremap(). We could change to use

[Part1 PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-13 Thread Tang Chen
From: Yinghai Lu Now we have pfn_mapped[] array, and max_low_pfn_mapped should not be used anymore. Users should use pfn_mapped[] or just 1UL<<(32-PAGE_SHIFT) instead. The only user of max_low_pfn_mapped is ACPI_INITRD_TABLE_OVERRIDE. We could change to use 1U<<(32_PAGE_SHIFT) with it, aka

[Part1 PATCH v5 03/22] x86, ACPI, mm: Kill max_low_pfn_mapped

2013-06-13 Thread Tang Chen
From: Yinghai Lu ying...@kernel.org Now we have pfn_mapped[] array, and max_low_pfn_mapped should not be used anymore. Users should use pfn_mapped[] or just 1UL(32-PAGE_SHIFT) instead. The only user of max_low_pfn_mapped is ACPI_INITRD_TABLE_OVERRIDE. We could change to use 1U(32_PAGE_SHIFT)