linux-toradex.git/arch/arm/kernel/head-common.S, branch v3.14.37 Linux kernel for Apalis and Colibri modules ARM: 7980/1: kernel: improve error message when LPAE config doesn't match CPU 2014-02-21T11:56:32+00:00 Thomas Petazzoni thomas.petazzoni@free-electrons.com 2014-02-18T16:02:54+00:00 b3634575930857724d5c3987a2739b0637999b4e Currently, when the kernel is configured with LPAE support, but the CPU doesn't support it, the error message is fairly cryptic: Error: unrecognized/unsupported processor variant (0x561f5811). This messages is normally shown when there is an issue when comparing the processor ID (CP15 0, c0, c0) with the values/masks described in proc-v7.S. However, the same message is displayed when LPAE support is enabled in the kernel configuration, but not available in the CPU, after looking at ID_MMFR0 (CP15 0, c0, c1, 4). Having the same error message is highly misleading. This commit improves this by showing a different error message when this situation occurs: Error: Kernel with LPAE support, but CPU does not support LPAE. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Currently, when the kernel is configured with LPAE support, but the
CPU doesn't support it, the error message is fairly cryptic:

  Error: unrecognized/unsupported processor variant (0x561f5811).

This messages is normally shown when there is an issue when comparing
the processor ID (CP15 0, c0, c0) with the values/masks described in
proc-v7.S. However, the same message is displayed when LPAE support is
enabled in the kernel configuration, but not available in the CPU,
after looking at ID_MMFR0 (CP15 0, c0, c1, 4). Having the same error
message is highly misleading.

This commit improves this by showing a different error message when
this situation occurs:

  Error: Kernel with LPAE support, but CPU does not support LPAE.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
arm: delete __cpuinit/__CPUINIT usage from all ARM users 2013-07-14T23:36:52+00:00 Paul Gortmaker paul.gortmaker@windriver.com 2013-06-17T19:43:14+00:00 8bd26e3a7e49af2697449bbcb7187a39dc85d672 The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. Note that some harmless section mismatch warnings may result, since notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c) and are flagged as __cpuinit -- so if we remove the __cpuinit from the arch specific callers, we will also get section mismatch warnings. As an intermediate step, we intend to turn the linux/init.h cpuinit related content into no-ops as early as possible, since that will get rid of these warnings. In any case, they are temporary and harmless. This removes all the ARM uses of the __cpuinit macros from C code, and all __CPUINIT from assembly code. It also had two ".previous" section statements that were paired off against __CPUINIT (aka .section ".cpuinit.text") that also get removed here. [1] https://lkml.org/lkml/2013/5/20/589 Cc: Russell King <linux@arm.linux.org.uk> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> 
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

Note that some harmless section mismatch warnings may result, since
notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
and are flagged as __cpuinit  -- so if we remove the __cpuinit from
the arch specific callers, we will also get section mismatch warnings.
As an intermediate step, we intend to turn the linux/init.h cpuinit
related content into no-ops as early as possible, since that will get
rid of these warnings.  In any case, they are temporary and harmless.

This removes all the ARM uses of the __cpuinit macros from C code,
and all __CPUINIT from assembly code.  It also had two ".previous"
section statements that were paired off against __CPUINIT
(aka .section ".cpuinit.text") that also get removed here.

[1] https://lkml.org/lkml/2013/5/20/589

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
ARM: 7780/1: add missing linker section markup to head-common.S 2013-07-09T08:51:35+00:00 Stephen Warren swarren@nvidia.com 2013-07-05T21:59:42+00:00 8c69d7af12265e5be9326110b695e010b47505bd 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> 
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>
ARM: make cr_alignment read-only #ifndef CONFIG_CPU_CP15 2013-01-31T20:44:45+00:00 Uwe Kleine-König u.kleine-koenig@pengutronix.de 2012-01-16T09:34:31+00:00 b849a60e0903b1c5430c3859864554662e127a8d This makes cr_alignment a constant 0 to break code that tries to modify the value as it's likely that it's built on wrong assumption when CONFIG_CPU_CP15 isn't defined. For code that is only reading the value 0 is more or less a fine value to report. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Message-Id: 1358413196-5609-2-git-send-email-u.kleine-koenig@pengutronix.de (v8) 
This makes cr_alignment a constant 0 to break code that tries to modify
the value as it's likely that it's built on wrong assumption when
CONFIG_CPU_CP15 isn't defined. For code that is only reading the value 0
is more or less a fine value to report.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Message-Id: 1358413196-5609-2-git-send-email-u.kleine-koenig@pengutronix.de (v8)
arm/dt: Make __vet_atags also accept a dtb image 2011-05-11T13:12:32+00:00 Grant Likely grant.likely@secretlab.ca 2011-04-28T20:27:20+00:00 4c2896e88d976d0e5b2213c64cde885f5677fa2b The dtb is passed to the kernel via register r2, which is the same method that is used to pass an atags pointer. This patch modifies __vet_atags to not clear r2 when it encounters a dtb image. v2: fixed bugs pointed out by Nicolas Pitre Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> 
The dtb is passed to the kernel via register r2, which is the same
method that is used to pass an atags pointer.  This patch modifies
__vet_atags to not clear r2 when it encounters a dtb image.

v2: fixed bugs pointed out by Nicolas Pitre

Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
ARM: Defer lookup of machine_type to setup.c 2011-02-15T16:36:44+00:00 Russell King rmk+kernel@arm.linux.org.uk 2011-01-12T17:50:42+00:00 6fc31d54443bdc25a8166be15e3920a7e39d195d Since the debug macros no longer depend on the machine type information, the machine type lookup can be deferred to setup_arch() in setup.c which simplifies the code somewhat. We also move the __error_a functionality into setup.c for displaying a message when a bad machine ID is passed to the kernel via the LL debug code. We also log this into the kernel ring buffer which makes it possible to retrieve the message via a debugger. Original idea from Grant Likely. Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Since the debug macros no longer depend on the machine type information,
the machine type lookup can be deferred to setup_arch() in setup.c which
simplifies the code somewhat.

We also move the __error_a functionality into setup.c for displaying a
message when a bad machine ID is passed to the kernel via the LL debug
code.  We also log this into the kernel ring buffer which makes it
possible to retrieve the message via a debugger.

Original idea from Grant Likely.

Acked-by: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: fix missing branch in __error_a 2011-01-15T11:19:19+00:00 Russell King rmk+kernel@arm.linux.org.uk 2011-01-15T11:19:19+00:00 cb4d3eaebb96616085f5a46a7d7e004ddd955b09 When DEBUG_LL is not set, we don't want __error_a re-entering __lookup_machine_type - we want it to go to the error function. This used to be the case before we reorganized the layout for hotplug cpu, as we used to fall through to __error. With the changed layout, we need an explicit branch here instead. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
When DEBUG_LL is not set, we don't want __error_a re-entering
__lookup_machine_type - we want it to go to the error function.  This
used to be the case before we reorganized the layout for hotplug cpu,
as we used to fall through to __error.  With the changed layout, we
need an explicit branch here instead.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Merge branch 'hotplug' into devel 2010-10-18T21:34:47+00:00 Russell King rmk+kernel@arm.linux.org.uk 2010-10-18T21:34:47+00:00 a0a55682b83fd5f012afadcf415b030d7424ae68 Conflicts: arch/arm/kernel/head-common.S 
Conflicts:
	arch/arm/kernel/head-common.S
ARM: cleanup lookup_machine_type data and ensure these are placed in __HEAD 2010-10-08T09:07:34+00:00 Russell King rmk+kernel@arm.linux.org.uk 2010-10-04T16:45:25+00:00 80924ac595f3ca32ec0a80cc1217c7019d3519ff Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: hotplug cpu: move __error and __error_p to cpuinit section 2010-10-08T09:07:33+00:00 Russell King rmk+kernel@arm.linux.org.uk 2010-10-04T16:39:20+00:00 c083c6609b290a650894f846270a9233401adc22 __error and __error_p may be used by secondary CPUs, so these need to be in the cpuinit section. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
__error and __error_p may be used by secondary CPUs, so these
need to be in the cpuinit section.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>