[PATCH v2 0/4] Miscellaneous nommu fixes

[PATCH v2 0/4] Miscellaneous nommu fixes

[Will Deacon]

Hello,

This is version two of the patches originally posted here:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/088158.html

Changes since v1 include:
	- kexec and ptrace patches now merged upstream
	- Rewrote vector copying fix to fit with 94e5a85b ("ARM: earlier
	  initialization of vectors page").
	- Added comment to membank truncation following feedback from
	  Nicolas and Sergei.
	- Based on 3.4-rc2

All feedback welcome,

Will


Will Deacon (4):
  ARM: nommu: fix typo in mm/Kconfig
  ARM: suspend: fix CPU suspend code for !CONFIG_MMU configurations
  ARM: mm: truncate memory banks to fit in 4GB space for classic MMU
  ARM: nommu: populate vectors page from paging_init

 arch/arm/kernel/setup.c   |   16 +++++++++++++-
 arch/arm/kernel/suspend.c |   52 ++++++++++++++++++++++++++-------------------
 arch/arm/mm/Kconfig       |    2 +-
 arch/arm/mm/nommu.c       |    2 +
 arch/arm/mm/proc-v6.S     |    6 ++++-
 arch/arm/mm/proc-v7.S     |   14 +++++++----
 6 files changed, 62 insertions(+), 30 deletions(-)

-- 
1.7.4.1

[PATCH v2 1/4] ARM: nommu: fix typo in mm/Kconfig

[Will Deacon]

The description for the CPU_HIGH_VECTOR Kconfig option for nommu builds
doesn't make any sense.

This patch fixes up the trivial grammatical error.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/mm/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 7edef91..7c8a7d8 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -723,7 +723,7 @@ config CPU_HIGH_VECTOR
 	bool "Select the High exception vector"
 	help
 	  Say Y here to select high exception vector(0xFFFF0000~).
-	  The exception vector can be vary depending on the platform
+	  The exception vector can vary depending on the platform
 	  design in nommu mode. If your platform needs to select
 	  high exception vector, say Y.
 	  Otherwise or if you are unsure, say N, and the low exception
-- 
1.7.4.1

[PATCH v2 2/4] ARM: suspend: fix CPU suspend code for !CONFIG_MMU configurations

[Will Deacon]

The ARM CPU suspend code can be selected even for a !CONFIG_MMU
configuration. The resulting kernel will not compile and, even if it did,
would access undefined co-processor registers when executing.

This patch fixes the v6 and v7 CPU suspend code for the nommu case.

Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/kernel/suspend.c |   52 ++++++++++++++++++++++++++-------------------
 arch/arm/mm/proc-v6.S     |    6 ++++-
 arch/arm/mm/proc-v7.S     |   14 +++++++----
 3 files changed, 44 insertions(+), 28 deletions(-)

diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 1794cc3..073601e 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -10,28 +10,7 @@
 extern int __cpu_suspend(unsigned long, int (*)(unsigned long));
 extern void cpu_resume_mmu(void);
 
-/*
- * This is called by __cpu_suspend() to save the state, and do whatever
- * flushing is required to ensure that when the CPU goes to sleep we have
- * the necessary data available when the caches are not searched.
- */
-void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32 *save_ptr)
-{
-	*save_ptr = virt_to_phys(ptr);
-
-	/* This must correspond to the LDM in cpu_resume() assembly */
-	*ptr++ = virt_to_phys(idmap_pgd);
-	*ptr++ = sp;
-	*ptr++ = virt_to_phys(cpu_do_resume);
-
-	cpu_do_suspend(ptr);
-
-	flush_cache_all();
-	outer_clean_range(*save_ptr, *save_ptr + ptrsz);
-	outer_clean_range(virt_to_phys(save_ptr),
-			  virt_to_phys(save_ptr) + sizeof(*save_ptr));
-}
-
+#ifdef CONFIG_MMU
 /*
  * Hide the first two arguments to __cpu_suspend - these are an implementation
  * detail which platform code shouldn't have to know about.
@@ -58,3 +37,32 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
 
 	return ret;
 }
+#else
+int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
+{
+	return __cpu_suspend(arg, fn);
+}
+#define	idmap_pgd	NULL
+#endif
+
+/*
+ * This is called by __cpu_suspend() to save the state, and do whatever
+ * flushing is required to ensure that when the CPU goes to sleep we have
+ * the necessary data available when the caches are not searched.
+ */
+void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32 *save_ptr)
+{
+	*save_ptr = virt_to_phys(ptr);
+
+	/* This must correspond to the LDM in cpu_resume() assembly */
+	*ptr++ = virt_to_phys(idmap_pgd);
+	*ptr++ = sp;
+	*ptr++ = virt_to_phys(cpu_do_resume);
+
+	cpu_do_suspend(ptr);
+
+	flush_cache_all();
+	outer_clean_range(*save_ptr, *save_ptr + ptrsz);
+	outer_clean_range(virt_to_phys(save_ptr),
+			  virt_to_phys(save_ptr) + sizeof(*save_ptr));
+}
diff --git a/arch/arm/mm/proc-v6.S b/arch/arm/mm/proc-v6.S
index 5900cd5..2f702fd 100644
--- a/arch/arm/mm/proc-v6.S
+++ b/arch/arm/mm/proc-v6.S
@@ -136,8 +136,10 @@ ENTRY(cpu_v6_set_pte_ext)
 ENTRY(cpu_v6_do_suspend)
 	stmfd	sp!, {r4 - r9, lr}
 	mrc	p15, 0, r4, c13, c0, 0	@ FCSE/PID
+#ifdef CONFIG_MMU
 	mrc	p15, 0, r5, c3, c0, 0	@ Domain ID
 	mrc	p15, 0, r6, c2, c0, 1	@ Translation table base 1
+#endif
 	mrc	p15, 0, r7, c1, c0, 1	@ auxiliary control register
 	mrc	p15, 0, r8, c1, c0, 2	@ co-processor access control
 	mrc	p15, 0, r9, c1, c0, 0	@ control register
@@ -154,14 +156,16 @@ ENTRY(cpu_v6_do_resume)
 	mcr	p15, 0, ip, c13, c0, 1	@ set reserved context ID
 	ldmia	r0, {r4 - r9}
 	mcr	p15, 0, r4, c13, c0, 0	@ FCSE/PID
+#ifdef CONFIG_MMU
 	mcr	p15, 0, r5, c3, c0, 0	@ Domain ID
 	ALT_SMP(orr	r1, r1, #TTB_FLAGS_SMP)
 	ALT_UP(orr	r1, r1, #TTB_FLAGS_UP)
 	mcr	p15, 0, r1, c2, c0, 0	@ Translation table base 0
 	mcr	p15, 0, r6, c2, c0, 1	@ Translation table base 1
+	mcr	p15, 0, ip, c2, c0, 2	@ TTB control register
+#endif
 	mcr	p15, 0, r7, c1, c0, 1	@ auxiliary control register
 	mcr	p15, 0, r8, c1, c0, 2	@ co-processor access control
-	mcr	p15, 0, ip, c2, c0, 2	@ TTB control register
 	mcr	p15, 0, ip, c7, c5, 4	@ ISB
 	mov	r0, r9			@ control register
 	b	cpu_resume_mmu
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index f1c8486..c6c9f5f 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -98,9 +98,11 @@ ENTRY(cpu_v7_do_suspend)
 	mrc	p15, 0, r4, c13, c0, 0	@ FCSE/PID
 	mrc	p15, 0, r5, c13, c0, 3	@ User r/o thread ID
 	stmia	r0!, {r4 - r5}
+#ifdef CONFIG_MMU
 	mrc	p15, 0, r6, c3, c0, 0	@ Domain ID
 	mrc	p15, 0, r7, c2, c0, 1	@ TTB 1
 	mrc	p15, 0, r11, c2, c0, 2	@ TTB control register
+#endif
 	mrc	p15, 0, r8, c1, c0, 0	@ Control register
 	mrc	p15, 0, r9, c1, c0, 1	@ Auxiliary control register
 	mrc	p15, 0, r10, c1, c0, 2	@ Co-processor access control
@@ -110,13 +112,14 @@ ENDPROC(cpu_v7_do_suspend)
 
 ENTRY(cpu_v7_do_resume)
 	mov	ip, #0
-	mcr	p15, 0, ip, c8, c7, 0	@ invalidate TLBs
 	mcr	p15, 0, ip, c7, c5, 0	@ invalidate I cache
 	mcr	p15, 0, ip, c13, c0, 1	@ set reserved context ID
 	ldmia	r0!, {r4 - r5}
 	mcr	p15, 0, r4, c13, c0, 0	@ FCSE/PID
 	mcr	p15, 0, r5, c13, c0, 3	@ User r/o thread ID
 	ldmia	r0, {r6 - r11}
+#ifdef CONFIG_MMU
+	mcr	p15, 0, ip, c8, c7, 0	@ invalidate TLBs
 	mcr	p15, 0, r6, c3, c0, 0	@ Domain ID
 #ifndef CONFIG_ARM_LPAE
 	ALT_SMP(orr	r1, r1, #TTB_FLAGS_SMP)
@@ -125,14 +128,15 @@ ENTRY(cpu_v7_do_resume)
 	mcr	p15, 0, r1, c2, c0, 0	@ TTB 0
 	mcr	p15, 0, r7, c2, c0, 1	@ TTB 1
 	mcr	p15, 0, r11, c2, c0, 2	@ TTB control register
-	mrc	p15, 0, r4, c1, c0, 1	@ Read Auxiliary control register
-	teq	r4, r9			@ Is it already set?
-	mcrne	p15, 0, r9, c1, c0, 1	@ No, so write it
-	mcr	p15, 0, r10, c1, c0, 2	@ Co-processor access control
 	ldr	r4, =PRRR		@ PRRR
 	ldr	r5, =NMRR		@ NMRR
 	mcr	p15, 0, r4, c10, c2, 0	@ write PRRR
 	mcr	p15, 0, r5, c10, c2, 1	@ write NMRR
+#endif	/* CONFIG_MMU */
+	mrc	p15, 0, r4, c1, c0, 1	@ Read Auxiliary control register
+	teq	r4, r9			@ Is it already set?
+	mcrne	p15, 0, r9, c1, c0, 1	@ No, so write it
+	mcr	p15, 0, r10, c1, c0, 2	@ Co-processor access control
 	isb
 	dsb
 	mov	r0, r8			@ control register
-- 
1.7.4.1

[PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU

[Will Deacon]

If a bank of memory spanning the 4GB boundary is added on a !CONFIG_LPAE
kernel then we will hang early during boot since the memory bank will
have wrapped around to zero.

This patch truncates memory banks for !LPAE configurations when the end
address is not representable in 32 bits.

Cc: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/kernel/setup.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index b914113..ebfac78 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -523,7 +523,21 @@ int __init arm_add_memory(phys_addr_t start, unsigned long size)
 	 */
 	size -= start & ~PAGE_MASK;
 	bank->start = PAGE_ALIGN(start);
-	bank->size  = size & PAGE_MASK;
+
+#ifndef CONFIG_LPAE
+	if (bank->start + size < bank->start) {
+		printk(KERN_CRIT "Truncating memory at 0x%08llx to fit in "
+			"32-bit physical address space\n", (long long)start);
+		/*
+		 * To ensure bank->start + bank->size is representable in
+		 * 32 bits, we use ULONG_MAX as the upper limit rather than 4GB.
+		 * This means we lose a page after masking.
+		 */
+		size = ULONG_MAX - bank->start;
+	}
+#endif
+
+	bank->size = size & PAGE_MASK;
 
 	/*
 	 * Check whether this memory region has non-zero size or
-- 
1.7.4.1

[PATCH v2 4/4] ARM: nommu: populate vectors page from paging_init

[Will Deacon]

Commit 94e5a85b ("ARM: earlier initialization of vectors page") made it
the responsibility of paging_init to initialise the vectors page.

This patch adds a call to early_trap_init for the !CONFIG_MMU case,
placing the vectors at CONFIG_VECTORS_BASE.

Cc: Jonathan Austin <jonathan.austin@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/mm/nommu.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 6486d2f..d51225f 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -13,6 +13,7 @@
 #include <asm/sections.h>
 #include <asm/page.h>
 #include <asm/setup.h>
+#include <asm/traps.h>
 #include <asm/mach/arch.h>
 
 #include "mm.h"
@@ -39,6 +40,7 @@ void __init sanity_check_meminfo(void)
  */
 void __init paging_init(struct machine_desc *mdesc)
 {
+	early_trap_init((void *)CONFIG_VECTORS_BASE);
 	bootmem_init();
 }
 
-- 
1.7.4.1

[PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU

[Nicolas Pitre]

On Wed, 11 Apr 2012, Will Deacon wrote:

> If a bank of memory spanning the 4GB boundary is added on a !CONFIG_LPAE
> kernel then we will hang early during boot since the memory bank will
> have wrapped around to zero.
> 
> This patch truncates memory banks for !LPAE configurations when the end
> address is not representable in 32 bits.
> 
> Cc: Nicolas Pitre <nico@fluxnic.net>
> Signed-off-by: Will Deacon <will.deacon@arm.com>

Acked-by: Nicolas Pitre <nico@linaro.org>

Now what if start = 1G and size = 5G? The size variable is an unsigned 
long, meaning that right now the size might be truncated to 1G.

> ---
>  arch/arm/kernel/setup.c |   16 +++++++++++++++-
>  1 files changed, 15 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index b914113..ebfac78 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -523,7 +523,21 @@ int __init arm_add_memory(phys_addr_t start, unsigned long size)
>  	 */
>  	size -= start & ~PAGE_MASK;
>  	bank->start = PAGE_ALIGN(start);
> -	bank->size  = size & PAGE_MASK;
> +
> +#ifndef CONFIG_LPAE
> +	if (bank->start + size < bank->start) {
> +		printk(KERN_CRIT "Truncating memory at 0x%08llx to fit in "
> +			"32-bit physical address space\n", (long long)start);
> +		/*
> +		 * To ensure bank->start + bank->size is representable in
> +		 * 32 bits, we use ULONG_MAX as the upper limit rather than 4GB.
> +		 * This means we lose a page after masking.
> +		 */
> +		size = ULONG_MAX - bank->start;
> +	}
> +#endif
> +
> +	bank->size = size & PAGE_MASK;
>  
>  	/*
>  	 * Check whether this memory region has non-zero size or
> -- 
> 1.7.4.1
> 

[PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU

[Will Deacon]

On Wed, Apr 11, 2012 at 03:44:22PM +0100, Nicolas Pitre wrote:
> On Wed, 11 Apr 2012, Will Deacon wrote:
> 
> > If a bank of memory spanning the 4GB boundary is added on a !CONFIG_LPAE
> > kernel then we will hang early during boot since the memory bank will
> > have wrapped around to zero.
> > 
> > This patch truncates memory banks for !LPAE configurations when the end
> > address is not representable in 32 bits.
> > 
> > Cc: Nicolas Pitre <nico@fluxnic.net>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> 
> Acked-by: Nicolas Pitre <nico@linaro.org>

Thanks Nicolas.

> Now what if start = 1G and size = 5G? The size variable is an unsigned 
> long, meaning that right now the size might be truncated to 1G.

membank->size is also an unsigned long, so I guess we'd have to create two
adjacent banks for this scenario. This is easy for ATAGs, because the
tag_mem32 structure has a u32 for size but obviously a DT blob could pass
something larger.

Will

[PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU

[Russell King - ARM Linux]

On Wed, Apr 11, 2012 at 10:44:22AM -0400, Nicolas Pitre wrote:
> On Wed, 11 Apr 2012, Will Deacon wrote:
> 
> > If a bank of memory spanning the 4GB boundary is added on a !CONFIG_LPAE
> > kernel then we will hang early during boot since the memory bank will
> > have wrapped around to zero.
> > 
> > This patch truncates memory banks for !LPAE configurations when the end
> > address is not representable in 32 bits.
> > 
> > Cc: Nicolas Pitre <nico@fluxnic.net>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> 
> Acked-by: Nicolas Pitre <nico@linaro.org>
> 
> Now what if start = 1G and size = 5G? The size variable is an unsigned 
> long, meaning that right now the size might be truncated to 1G.

There's a solution to that which is quite easy to do: convert the bank
information to PFNs instead of addresses.  That will probably eliminate
some corner cases with partial pages which would be desirable too.

Re: [PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU

[Russell King - ARM Linux]

On Wed, Apr 11, 2012 at 04:52:32PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 11, 2012 at 10:44:22AM -0400, Nicolas Pitre wrote:
> > On Wed, 11 Apr 2012, Will Deacon wrote:
> > 
> > > If a bank of memory spanning the 4GB boundary is added on a !CONFIG_LPAE
> > > kernel then we will hang early during boot since the memory bank will
> > > have wrapped around to zero.
> > > 
> > > This patch truncates memory banks for !LPAE configurations when the end
> > > address is not representable in 32 bits.
> > > 
> > > Cc: Nicolas Pitre <nico@fluxnic.net>
> > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > 
> > Acked-by: Nicolas Pitre <nico@linaro.org>
> > 
> > Now what if start = 1G and size = 5G? The size variable is an unsigned 
> > long, meaning that right now the size might be truncated to 1G.
> 
> There's a solution to that which is quite easy to do: convert the bank
> information to PFNs instead of addresses.  That will probably eliminate
> some corner cases with partial pages which would be desirable too.

Of course, what prevents us doing that conversion sanely is all the
shite platform code doing crap stuff like this:

arch/arm/mach-msm/board-halibut.c:      mi->bank[0].start = PHYS_OFFSET;
arch/arm/mach-msm/board-halibut.c:      mi->bank[0].size = (101*1024*1024);

which I went through everything a few years ago and eliminated all this
crap.  It's back now.  Sod it, we'll stick with the current 4GiB limited
way as long as we have platform maintainers who do this kind of crappy
hack.

While here, I propose to delete these:

arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].start = PHYS_OFFSET;
arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].size = (219*1024*1024);
arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].start = MSM_HIGHMEM_BASE;
arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].node = PHYS_TO_NID(MSM_HIGHMEM_BASE);
arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].size = MSM_HIGHMEM_SIZE;
arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].start = PHYS_OFFSET;
arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (84*1024*1024);
arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);

because they haven't been buildable since 7th May 2010 (that's 23 months
ago), and no one has reported any build errors with them.  They're only
receiving updates from other sweeps and nothing more.  This all means no
one is even attempting to build this code.  It's pointless having
unbuildable code in the kernel, and it's nothing more than a useless
maintanence burden.

[PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU

[Russell King - ARM Linux]

On Wed, Apr 11, 2012 at 04:52:32PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 11, 2012 at 10:44:22AM -0400, Nicolas Pitre wrote:
> > On Wed, 11 Apr 2012, Will Deacon wrote:
> > 
> > > If a bank of memory spanning the 4GB boundary is added on a !CONFIG_LPAE
> > > kernel then we will hang early during boot since the memory bank will
> > > have wrapped around to zero.
> > > 
> > > This patch truncates memory banks for !LPAE configurations when the end
> > > address is not representable in 32 bits.
> > > 
> > > Cc: Nicolas Pitre <nico@fluxnic.net>
> > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > 
> > Acked-by: Nicolas Pitre <nico@linaro.org>
> > 
> > Now what if start = 1G and size = 5G? The size variable is an unsigned 
> > long, meaning that right now the size might be truncated to 1G.
> 
> There's a solution to that which is quite easy to do: convert the bank
> information to PFNs instead of addresses.  That will probably eliminate
> some corner cases with partial pages which would be desirable too.

Of course, what prevents us doing that conversion sanely is all the
shite platform code doing crap stuff like this:

arch/arm/mach-msm/board-halibut.c:      mi->bank[0].start = PHYS_OFFSET;
arch/arm/mach-msm/board-halibut.c:      mi->bank[0].size = (101*1024*1024);

which I went through everything a few years ago and eliminated all this
crap.  It's back now.  Sod it, we'll stick with the current 4GiB limited
way as long as we have platform maintainers who do this kind of crappy
hack.

While here, I propose to delete these:

arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].start = PHYS_OFFSET;
arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].size = (219*1024*1024);
arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].start = MSM_HIGHMEM_BASE;
arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].node = PHYS_TO_NID(MSM_HIGHMEM_BASE);
arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].size = MSM_HIGHMEM_SIZE;
arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].start = PHYS_OFFSET;
arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (84*1024*1024);
arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);

because they haven't been buildable since 7th May 2010 (that's 23 months
ago), and no one has reported any build errors with them.  They're only
receiving updates from other sweeps and nothing more.  This all means no
one is even attempting to build this code.  It's pointless having
unbuildable code in the kernel, and it's nothing more than a useless
maintanence burden.

Re: [PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU

[David Brown]

On Wed, Apr 11, 2012 at 05:27:30PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 11, 2012 at 04:52:32PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Apr 11, 2012 at 10:44:22AM -0400, Nicolas Pitre wrote:
> > > On Wed, 11 Apr 2012, Will Deacon wrote:
> > > 
> > > > If a bank of memory spanning the 4GB boundary is added on a !CONFIG_LPAE
> > > > kernel then we will hang early during boot since the memory bank will
> > > > have wrapped around to zero.
> > > > 
> > > > This patch truncates memory banks for !LPAE configurations when the end
> > > > address is not representable in 32 bits.
> > > > 
> > > > Cc: Nicolas Pitre <nico@fluxnic.net>
> > > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > 
> > > Acked-by: Nicolas Pitre <nico@linaro.org>
> > > 
> > > Now what if start = 1G and size = 5G? The size variable is an unsigned 
> > > long, meaning that right now the size might be truncated to 1G.
> > 
> > There's a solution to that which is quite easy to do: convert the bank
> > information to PFNs instead of addresses.  That will probably eliminate
> > some corner cases with partial pages which would be desirable too.
> 
> Of course, what prevents us doing that conversion sanely is all the
> shite platform code doing crap stuff like this:
> 
> arch/arm/mach-msm/board-halibut.c:      mi->bank[0].start = PHYS_OFFSET;
> arch/arm/mach-msm/board-halibut.c:      mi->bank[0].size = (101*1024*1024);
> 
> which I went through everything a few years ago and eliminated all this
> crap.  It's back now.  Sod it, we'll stick with the current 4GiB limited
> way as long as we have platform maintainers who do this kind of crappy
> hack.

I'm not sure there are even any working "halibut" targets (MSM7201
SURF).  It wasn't a generally available target.  I think the only
in-use fish target is trout (HTC Dream).  Although, it seems that
every time I think this, someone will speak up about one of these
targets.

> While here, I propose to delete these:
> 
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].start = PHYS_OFFSET;
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].size = (219*1024*1024);
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].start = MSM_HIGHMEM_BASE;
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].node = PHYS_TO_NID(MSM_HIGHMEM_BASE);
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].size = MSM_HIGHMEM_SIZE;
> arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].start = PHYS_OFFSET;
> arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (84*1024*1024);
> arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> 
> because they haven't been buildable since 7th May 2010 (that's 23 months
> ago), and no one has reported any build errors with them.  They're only
> receiving updates from other sweeps and nothing more.  This all means no
> one is even attempting to build this code.  It's pointless having
> unbuildable code in the kernel, and it's nothing more than a useless
> maintanence burden.

I don't think these were ever built.  They were never added to the
Makefiles.

Patch to follow.

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU

[David Brown]

On Wed, Apr 11, 2012 at 05:27:30PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 11, 2012 at 04:52:32PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Apr 11, 2012 at 10:44:22AM -0400, Nicolas Pitre wrote:
> > > On Wed, 11 Apr 2012, Will Deacon wrote:
> > > 
> > > > If a bank of memory spanning the 4GB boundary is added on a !CONFIG_LPAE
> > > > kernel then we will hang early during boot since the memory bank will
> > > > have wrapped around to zero.
> > > > 
> > > > This patch truncates memory banks for !LPAE configurations when the end
> > > > address is not representable in 32 bits.
> > > > 
> > > > Cc: Nicolas Pitre <nico@fluxnic.net>
> > > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > 
> > > Acked-by: Nicolas Pitre <nico@linaro.org>
> > > 
> > > Now what if start = 1G and size = 5G? The size variable is an unsigned 
> > > long, meaning that right now the size might be truncated to 1G.
> > 
> > There's a solution to that which is quite easy to do: convert the bank
> > information to PFNs instead of addresses.  That will probably eliminate
> > some corner cases with partial pages which would be desirable too.
> 
> Of course, what prevents us doing that conversion sanely is all the
> shite platform code doing crap stuff like this:
> 
> arch/arm/mach-msm/board-halibut.c:      mi->bank[0].start = PHYS_OFFSET;
> arch/arm/mach-msm/board-halibut.c:      mi->bank[0].size = (101*1024*1024);
> 
> which I went through everything a few years ago and eliminated all this
> crap.  It's back now.  Sod it, we'll stick with the current 4GiB limited
> way as long as we have platform maintainers who do this kind of crappy
> hack.

I'm not sure there are even any working "halibut" targets (MSM7201
SURF).  It wasn't a generally available target.  I think the only
in-use fish target is trout (HTC Dream).  Although, it seems that
every time I think this, someone will speak up about one of these
targets.

> While here, I propose to delete these:
> 
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].start = PHYS_OFFSET;
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].size = (219*1024*1024);
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].start = MSM_HIGHMEM_BASE;
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].node = PHYS_TO_NID(MSM_HIGHMEM_BASE);
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].size = MSM_HIGHMEM_SIZE;
> arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].start = PHYS_OFFSET;
> arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (84*1024*1024);
> arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> 
> because they haven't been buildable since 7th May 2010 (that's 23 months
> ago), and no one has reported any build errors with them.  They're only
> receiving updates from other sweeps and nothing more.  This all means no
> one is even attempting to build this code.  It's pointless having
> unbuildable code in the kernel, and it's nothing more than a useless
> maintanence burden.

I don't think these were ever built.  They were never added to the
Makefiles.

Patch to follow.

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU

[Daniel Walker]

On Wed, Apr 11, 2012 at 05:27:30PM +0100, Russell King - ARM Linux wrote:
> Of course, what prevents us doing that conversion sanely is all the
> shite platform code doing crap stuff like this:
> 
> arch/arm/mach-msm/board-halibut.c:      mi->bank[0].start = PHYS_OFFSET;
> arch/arm/mach-msm/board-halibut.c:      mi->bank[0].size = (101*1024*1024);
> 
> which I went through everything a few years ago and eliminated all this
> crap.  It's back now.  Sod it, we'll stick with the current 4GiB limited
> way as long as we have platform maintainers who do this kind of crappy
> hack.
> 
> While here, I propose to delete these:
> 
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].start = PHYS_OFFSET;
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].size = (219*1024*1024);
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].start = MSM_HIGHMEM_BASE;
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].node = PHYS_TO_NID(MSM_HIGHMEM_BASE);
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].size = MSM_HIGHMEM_SIZE;
> arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].start = PHYS_OFFSET;
> arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (84*1024*1024);
> arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> 
> because they haven't been buildable since 7th May 2010 (that's 23 months
> ago), and no one has reported any build errors with them.  They're only
> receiving updates from other sweeps and nothing more.  This all means no
> one is even attempting to build this code.  It's pointless having
> unbuildable code in the kernel, and it's nothing more than a useless
> maintanence burden.


It can't be that hard to fix.. I'll look into cleaning it up.

Daniel

[PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU

[Daniel Walker]

On Wed, Apr 11, 2012 at 05:27:30PM +0100, Russell King - ARM Linux wrote:
> Of course, what prevents us doing that conversion sanely is all the
> shite platform code doing crap stuff like this:
> 
> arch/arm/mach-msm/board-halibut.c:      mi->bank[0].start = PHYS_OFFSET;
> arch/arm/mach-msm/board-halibut.c:      mi->bank[0].size = (101*1024*1024);
> 
> which I went through everything a few years ago and eliminated all this
> crap.  It's back now.  Sod it, we'll stick with the current 4GiB limited
> way as long as we have platform maintainers who do this kind of crappy
> hack.
> 
> While here, I propose to delete these:
> 
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].start = PHYS_OFFSET;
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].size = (219*1024*1024);
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].start = MSM_HIGHMEM_BASE;
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].node = PHYS_TO_NID(MSM_HIGHMEM_BASE);
> arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].size = MSM_HIGHMEM_SIZE;
> arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].start = PHYS_OFFSET;
> arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (84*1024*1024);
> arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> 
> because they haven't been buildable since 7th May 2010 (that's 23 months
> ago), and no one has reported any build errors with them.  They're only
> receiving updates from other sweeps and nothing more.  This all means no
> one is even attempting to build this code.  It's pointless having
> unbuildable code in the kernel, and it's nothing more than a useless
> maintanence burden.


It can't be that hard to fix.. I'll look into cleaning it up.

Daniel

Re: [PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU

[Russell King - ARM Linux]

On Wed, Apr 11, 2012 at 10:38:50AM -0700, Daniel Walker wrote:
> On Wed, Apr 11, 2012 at 05:27:30PM +0100, Russell King - ARM Linux wrote:
> > While here, I propose to delete these:
> > 
> > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].start = PHYS_OFFSET;
> > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].size = (219*1024*1024);
> > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].start = MSM_HIGHMEM_BASE;
> > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].node = PHYS_TO_NID(MSM_HIGHMEM_BASE);
> > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].size = MSM_HIGHMEM_SIZE;
> > arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].start = PHYS_OFFSET;
> > arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> > arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (84*1024*1024);
> > arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> > arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> > 
> > because they haven't been buildable since 7th May 2010 (that's 23 months
> > ago), and no one has reported any build errors with them.  They're only
> > receiving updates from other sweeps and nothing more.  This all means no
> > one is even attempting to build this code.  It's pointless having
> > unbuildable code in the kernel, and it's nothing more than a useless
> > maintanence burden.
> 
> 
> It can't be that hard to fix.. I'll look into cleaning it up.

What's the point of fixing code which isn't being used by anyone?  As I
said above, it's a maintanence burden and if its not being used it needs
to be removed.

[PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU

[Russell King - ARM Linux]

On Wed, Apr 11, 2012 at 10:38:50AM -0700, Daniel Walker wrote:
> On Wed, Apr 11, 2012 at 05:27:30PM +0100, Russell King - ARM Linux wrote:
> > While here, I propose to delete these:
> > 
> > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].start = PHYS_OFFSET;
> > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].size = (219*1024*1024);
> > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].start = MSM_HIGHMEM_BASE;
> > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].node = PHYS_TO_NID(MSM_HIGHMEM_BASE);
> > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].size = MSM_HIGHMEM_SIZE;
> > arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].start = PHYS_OFFSET;
> > arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> > arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (84*1024*1024);
> > arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> > arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> > 
> > because they haven't been buildable since 7th May 2010 (that's 23 months
> > ago), and no one has reported any build errors with them.  They're only
> > receiving updates from other sweeps and nothing more.  This all means no
> > one is even attempting to build this code.  It's pointless having
> > unbuildable code in the kernel, and it's nothing more than a useless
> > maintanence burden.
> 
> 
> It can't be that hard to fix.. I'll look into cleaning it up.

What's the point of fixing code which isn't being used by anyone?  As I
said above, it's a maintanence burden and if its not being used it needs
to be removed.

Re: [PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU

[Daniel Walker]

On Wed, Apr 11, 2012 at 06:40:24PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 11, 2012 at 10:38:50AM -0700, Daniel Walker wrote:
> > On Wed, Apr 11, 2012 at 05:27:30PM +0100, Russell King - ARM Linux wrote:
> > > While here, I propose to delete these:
> > > 
> > > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].start = PHYS_OFFSET;
> > > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> > > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].size = (219*1024*1024);
> > > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].start = MSM_HIGHMEM_BASE;
> > > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].node = PHYS_TO_NID(MSM_HIGHMEM_BASE);
> > > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].size = MSM_HIGHMEM_SIZE;
> > > arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].start = PHYS_OFFSET;
> > > arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> > > arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (84*1024*1024);
> > > arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> > > arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> > > 
> > > because they haven't been buildable since 7th May 2010 (that's 23 months
> > > ago), and no one has reported any build errors with them.  They're only
> > > receiving updates from other sweeps and nothing more.  This all means no
> > > one is even attempting to build this code.  It's pointless having
> > > unbuildable code in the kernel, and it's nothing more than a useless
> > > maintanence burden.
> > 
> > 
> > It can't be that hard to fix.. I'll look into cleaning it up.
> 
> What's the point of fixing code which isn't being used by anyone?  As I
> said above, it's a maintanence burden and if its not being used it needs
> to be removed.
> 

Aren't there whole are sub-architectures that don't even build ? I think
something that's a work in progress is fine, as long as someone (i.e.
me) plans to get back to it at some point.

I also said that _I_ would make it build .. So someone is going to use
it, and it is going to build.

Daniel

[PATCH v2 3/4] ARM: mm: truncate memory banks to fit in 4GB space for classic MMU

[Daniel Walker]

On Wed, Apr 11, 2012 at 06:40:24PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 11, 2012 at 10:38:50AM -0700, Daniel Walker wrote:
> > On Wed, Apr 11, 2012 at 05:27:30PM +0100, Russell King - ARM Linux wrote:
> > > While here, I propose to delete these:
> > > 
> > > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].start = PHYS_OFFSET;
> > > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> > > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[0].size = (219*1024*1024);
> > > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].start = MSM_HIGHMEM_BASE;
> > > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].node = PHYS_TO_NID(MSM_HIGHMEM_BASE);
> > > arch/arm/mach-msm/board-mahimahi.c:     mi->bank[1].size = MSM_HIGHMEM_SIZE;
> > > arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].start = PHYS_OFFSET;
> > > arch/arm/mach-msm/board-sapphire.c:     mi->bank[0].node = PHYS_TO_NID(PHYS_OFFSET);
> > > arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (84*1024*1024);
> > > arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> > > arch/arm/mach-msm/board-sapphire.c:             mi->bank[0].size = (101*1024*1024);
> > > 
> > > because they haven't been buildable since 7th May 2010 (that's 23 months
> > > ago), and no one has reported any build errors with them.  They're only
> > > receiving updates from other sweeps and nothing more.  This all means no
> > > one is even attempting to build this code.  It's pointless having
> > > unbuildable code in the kernel, and it's nothing more than a useless
> > > maintanence burden.
> > 
> > 
> > It can't be that hard to fix.. I'll look into cleaning it up.
> 
> What's the point of fixing code which isn't being used by anyone?  As I
> said above, it's a maintanence burden and if its not being used it needs
> to be removed.
> 

Aren't there whole are sub-architectures that don't even build ? I think
something that's a work in progress is fine, as long as someone (i.e.
me) plans to get back to it at some point.

I also said that _I_ would make it build .. So someone is going to use
it, and it is going to build.

Daniel