diff options
| author | Stephen Warren <swarren@nvidia.com> | 2013-07-05 22:59:42 +0100 |
|---|---|---|
| committer | Russell King <rmk+kernel@arm.linux.org.uk> | 2013-07-09 09:51:35 +0100 |
| commit | 8c69d7af12265e5be9326110b695e010b47505bd (patch) | |
| tree | ce48ba08591e7f4db23bb84cf434bbf9c20cf5db /arch/arm/kernel/head-common.S | |
| parent | 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376 (diff) | |
| download | talos-obmc-linux-8c69d7af12265e5be9326110b695e010b47505bd.tar.gz talos-obmc-linux-8c69d7af12265e5be9326110b695e010b47505bd.zip | |
ARM: 7780/1: add missing linker section markup to head-common.S
Macro __INIT is used to place various code in head-common.S into the init
section. This should be matched by a closing __FINIT. Also, add an
explicit ".text" to ensure subsequent code is placed into the correct
section; __FINIT is simply a closing marker to match __INIT and doesn't
guarantee to revert to .text.
This historically caused no problem, because macro __CPUINIT was used at
the exact location where __FINIT was missing, which then placed following
code into the cpuinit section. However, with commit 22f0a2736 "init.h:
remove __cpuinit sections from the kernel" applied, __CPUINIT becomes a
no-op, thus leaving all this code in the init section, rather than the
regular text section. This caused issues such as secondary CPU boot
failures or crashes.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Diffstat (limited to 'arch/arm/kernel/head-common.S')
| -rw-r--r-- | arch/arm/kernel/head-common.S | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S index 5b391a689b47..76ab5ca50610 100644 --- a/arch/arm/kernel/head-common.S +++ b/arch/arm/kernel/head-common.S @@ -133,6 +133,9 @@ ENTRY(lookup_processor_type) ldmfd sp!, {r4 - r6, r9, pc} ENDPROC(lookup_processor_type) + __FINIT + .text + /* * Read processor ID register (CP#15, CR0), and look up in the linker-built * supported processor list. Note that we can't use the absolute addresses |
