Miscellaneous nommu fixes
Subsystems (2)
v2 cover Miscellaneous nommu fixes
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(-)
Signature · 1 line
1.7.4.1
PATCH v2 1/4 ARM: nommu: fix typo in mm/Kconfig
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.
--- arch/arm/mm/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/mm/Kconfig +1 -1
@@ -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
Signature · 1 line
1.7.4.1
PATCH v2 2/4 ARM: suspend: fix CPU suspend code for !CONFIG_MMU configurations
In reply to Will DeaconThe 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.
--- 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(-)
arch/arm/kernel/suspend.c +30 -22
@@ -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)); +}
arch/arm/mm/proc-v6.S +5 -1
@@ -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
arch/arm/mm/proc-v7.S +9 -5
@@ -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
Signature · 1 line
1.7.4.1
PATCH v2 3/4 ARM: mm: truncate memory banks to fit in 4GB space for classic MMU
In reply to Will DeaconIf 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.
--- arch/arm/kernel/setup.c | 16 +++++++++++++++- 1 files changed, 15 insertions(+), 1 deletions(-)
arch/arm/kernel/setup.c +15 -1
@@ -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
Signature · 1 line
1.7.4.1
PATCH v2 3/4 ARM: mm: truncate memory banks to fit in 4GB space for classic MMU
Quoted 9 lines · 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 <[email protected]>Signed-off-by Will Deacon <[email protected]>
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.
Quoted 34 lines
--- arch/arm/kernel/setup.c | 16 +++++++++++++++- 1 files changed, 15 insertions(+), 1 deletions(-)arch/arm/kernel/setup.c +15
-1@@ -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 Signature · 1 line
1.7.4.1
PATCH v2 3/4 ARM: mm: truncate memory banks to fit in 4GB space for classic MMU
Quoted 6 lines · Nicolas Pitre
Quoted 4 lines · 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.
Quoted 7 lines
Quoted 5 lines
This patch truncates memory banks for !LPAE configurations when the end address is not representable in 32 bits.
Cc Nicolas Pitre <[email protected]>Signed-off-by Will Deacon <[email protected]>Acked-by Nicolas Pitre <[email protected]>
Thanks Nicolas.
Quoted 2 lines
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
In reply to Nicolas PitreQuoted 9 lines · Nicolas Pitre
Quoted 7 lines · 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.
Quoted 7 lines
Quoted 2 lines
Cc Nicolas Pitre <[email protected]>Signed-off-by Will Deacon <[email protected]>Acked-by Nicolas Pitre <[email protected]>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.
PATCH v2 3/4 ARM: mm: truncate memory banks to fit in 4GB space for classic MMU
Quoted 13 lines · Russell King - ARM Linux
Quoted 12 lines · Nicolas Pitre
Quoted 9 lines · 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 <[email protected]>Signed-off-by Will Deacon <[email protected]>
Quoted 8 lines
Quoted 4 lines
Acked-by Nicolas Pitre <[email protected]>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
Quoted 26 lines · Russell King - ARM Linux
Quoted 13 lines · Russell King - ARM Linux
Quoted 12 lines · Nicolas Pitre
Quoted 9 lines · 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 <[email protected]>Signed-off-by Will Deacon <[email protected]>Quoted 8 lines
Quoted 4 lines
Acked-by Nicolas Pitre <[email protected]>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:
Quoted 7 lines
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.
Quoted 14 lines
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);
Quoted 6 lines
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
Signature · 2 lines
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
In reply to Russell King - ARM LinuxQuoted 25 lines · Russell King - ARM Linux
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);
Quoted 6 lines
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
Quoted 23 lines · Daniel Walker
Quoted 14 lines · Russell King - ARM Linux
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);Quoted 6 lines
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.
Quoted 1 line
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
Quoted 24 lines · Russell King - ARM Linux
Quoted 23 lines · Daniel Walker
Quoted 20 lines · Russell King - ARM Linux
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.
Quoted 6 lines
Quoted 1 line
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 4/4 ARM: nommu: populate vectors page from paging_init
In reply to Will DeaconCommit 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.
--- arch/arm/mm/nommu.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
arch/arm/mm/nommu.c +2 -0
@@ -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 (); }
Signature · 1 line
1.7.4.1