In a preemptible kernel, vfp_set() can be preempted, causing the
hardware VFP context to be switched while the thread vfp state is
being read and modified. This leads to a race condition which can
cause the thread vfp state to become corrupted if lazy VFP context
save occurs due to preemption in between the time thread->vfpstate
is read and the time the modified state is written back.
This may occur if preemption occurs during the execution of a
ptrace() call which modifies the VFP register state of a thread.
Such instances should be very rare in most realistic scenarios --
none has been reported, so far as I am aware. Only uniprocessor
systems should be affected, since VFP context save is not currently
lazy in SMP kernels.
The problem was introduced by my earlier patch migrating to use
regsets to implement ptrace.
This patch does a vfp_sync_hwstate() before reading
thread->vfpstate, to make sure that the thread's VFP state is not
live in the hardware registers while the registers are modified.
Thanks to Will Deacon for spotting this.
Cc: stable <[email protected]>
Signed-off-by: Dave Martin <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Russell King <[email protected]>
Compiled device tree blobs shouldn't be committed in the kernel
tree, so ideally git should ignore them.
This patch will enable ignoring of any .dtb files which appear in
arch/arm/boot/
Signed-off-by: Dave Martin <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
Activation conditions for a workaround should not be encoded in the
workaround's direct dependencies if this makes otherwise reasonable
configuration choices impossible.
This patches uses the SMP/UP patching facilities instead to compile
out the workaround if the configuration means that it is definitely
not needed.
This means that configs for buggy silicon can simply select
ARM_ERRATA_751472, without preventing a UP kernel from being built
or duplicatiing knowledge about when to activate the workaround.
This seems the correct way to do things, because the erratum is a
property of the silicon, irrespective of what the kernel config
happens to be.
Signed-off-by: Dave Martin <[email protected]>
Signed-off-by: Russell King <[email protected]>
Activation conditions for a workaround should not be encoded in the
workaround's direct dependencies if this makes otherwise reasonable
configuration choices impossible.
The workaround for erratum 720789 only affects a code path which is
not active in UP kernels; hence it should be safe to turn on in UP
kernels, without penalty.
This patch simply removes the extra dependency on SMP from Kconfig.
This means that configs for buggy silicon can simply select
ARM_ERRATA_720789, without preventing a UP kernel from being built
or duplicatiing knowledge about when to activate the workaround.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Russell King <[email protected]>
The i.MX6 Quad SoC will work without the l2x0 L2 cache controller
support built into the kernel, so this patch removes the dependency
on CACHE_L2X0.
This makes the l2x0 support optional, so that it can be turned off
when desired for debugging purposes etc.
Since SOC_IMX6Q already depends on ARCH_IMX_V6_V7 and
ARCH_IMX_V6_V7 selects MIGHT_HAVE_CACHE_L2X0, there is no need to
select that option explicitly from SOC_IMX6Q.
Thanks to Shawn Guo for this suggestion. [1]
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074602.html
Acked-by: Shawn Guo <[email protected]>
Tested-by: Shawn Guo <[email protected]>
Acked-by: Sascha Hauer <[email protected]>
If running in the Normal World on a TrustZone-enabled SoC, Linux
does not have complete control over the L2 cache controller
configuration. The kernel cannot work reliably on such platforms
without the l2x0 cache support code built in.
This patch unconditionally enables l2x0 support for the Highbank
SoC.
Thanks to Rob Herring for this suggestion. [1]
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Rob Herring <[email protected]>
If running in the Normal World on a TrustZone-enabled SoC, Linux
does not have complete control over the L2 cache controller
configuration. The kernel cannot work reliably on such platforms
without the l2x0 cache support code built in.
This patch unconditionally enables l2x0 support for the OMAP4 SoCs.
Thanks to Rob Herring for this suggestion. [1]
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Making SMP depend on (huge list of MACH_ and ARCH_ configs) is
bothersome to maintain and likely to lead to merge conflicts.
This patch moves the knowledge of which platforms are SMP-capable
to the individual machines. To enable this, a new HAVE_SMP config
option is introduced to allow machines to indicate that they can
run in a SMP configuration.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Linus Walleij <[email protected]>
(for nomadik, ux500)
Acked-by: Tony Lindgren <[email protected]>
(for omap)
Acked-by: Kukjin Kim <[email protected]>
(for exynos)
Acked-by: Sascha Hauer <[email protected]>
(for imx)
Acked-by: Olof Johansson <[email protected]>
(for tegra)
Making CACHE_L2X0 depend on (huge list of MACH_ and ARCH_ configs)
is bothersome to maintain and likely to lead to merge conflicts.
This patch moves the knowledge of which platforms have a L2x0 or
PL310 cache controller to the individual machines. To enable this,
a new MIGHT_HAVE_CACHE_L2X0 config option is introduced to allow
machines to indicate that they may have such a cache controller
independently of each other.
Boards/SoCs which cannot reliably operate without the L2 cache
controller support will need to select CACHE_L2X0 directly from
their own Kconfigs instead. This applies to some TrustZone-enabled
boards where Linux runs in the Normal World, for example.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Anton Vorontsov <[email protected]>
(for cns3xxx)
Acked-by: Tony Lindgren <[email protected]>
(for omap)
Acked-by: Shawn Guo <[email protected]>
(for imx)
Acked-by: Kukjin Kim <[email protected]>
(for exynos)
Acked-by: Sascha Hauer <[email protected]>
(for imx)
Acked-by: Olof Johansson <[email protected]>
(for tegra)
Data read direct from device tree properties will be in the device
tree's native endianness (i.e., big-endian).
This patch uses of_property_read_u32() to read the bus-width
property in host byte order instead.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Pawel Moll <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ARMv6 and later processors have the REV16 instruction, which swaps
the bytes within each halfword of a register value.
This is already used to implement swab16(), but since the native
operation performaed by REV16 is actually swahb32(), this patch
renames the existing swab16() helper accordingly and defines
__arch_swab16() in terms of it. This allows calls to both swab16()
and swahb32() to be optimised.
The compiler's generated code might improve someday, but as of
4.5.2 the code generated for pure C implementing these 16-bit
bytesswaps remains pessimal.
swahb32() is useful for converting 32-bit Thumb instructions
between integer and memory representation on BE8 platforms (among
other uses).
Signed-off-by: Dave Martin <[email protected]>
Reviewed-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
This patch adds the necessary support in file2alias.c to define
suitable aliases based on the amba_id table in AMBA driver modules.
This should be sufficient to allow such modules to be auto-loaded
via udev. The AMBA bus driver's uevent hotplug code is also
modified to pass an approriate MODALIAS string in the event.
For simplicity, the AMBA ID is treated an an opaque 32-bit numeber.
Module alises use patterns as appropriate to describe the value-
mask pairs described in the driver's amba_id list.
The proposed alias format is (extended regex):
^amba:d(HEX){8}$
Where HEX is a single upper-case HEX digit or a pattern (? or []
expression) matching a single upper-case HEX digit, as expected by
udev.
"d" is short for "device", following existing alias naming
conventions for other device types. This adds some flexibility for
unambiguously extending the alias format in the future by adding
additional leading and trailing fields, if this turns out to be
necessary.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Pawel Moll <[email protected]>
The general kernel infrastructure for adding module alises during
module post processing expects the affected device type
identification structures in a common header
<linux/mod_devicetable.h>.
This patch simple moves struct amba_id to the common header, and
adds the appropriate include in <linux/amba/bus.h>.
Signed-off-by: Dave Martin <[email protected]>
When v6 and >=v7 boards are supported in the same kernel, the
__und_usr code currently makes a build-time assumption that Thumb-2
instructions occurring in userspace don't need to be supported.
Strictly speaking this is incorrect.
This patch fixes the above case by doing a run-time check on the
CPU architecture in these cases. This only affects kernels which
support v6 and >=v7 CPUs together: plain v6 and plain v7 kernels
are unaffected.
Signed-off-by: Dave Martin <[email protected]>
Reviewed-by: Jon Medhurst <[email protected]>
Signed-off-by: Russell King <[email protected]>
When testing whether a Thumb-2 instruction is 32 bits long or not,
the masking done in order to test bits 11-15 of the first
instruction halfword won't affect the result of the comparison, so
remove it.
Signed-off-by: Dave Martin <[email protected]>
Reviewed-by: Jon Medhurst <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
The CPU architecture really should not be changing at runtime, so
make it a global variable instead of a function.
The cpu_architecture() function declared in <asm/system.h> remains
the correct way to read this variable from C code.
Signed-off-by: Dave Martin <[email protected]>
Reviewed-by: Jon Medhurst <[email protected]>
Signed-off-by: Russell King <[email protected]>
The SMSC911X_USE_16BIT needs to be set when using 16-bit register
access. However, currently no flag is set if the device tree
doesn't specify 32-bit access, resulting in a BUG() and a non-
working driver when 16-bit register access is configured for
smsc911x in the DT.
This patch should set the SMSC911X_USE_16BIT flag in a manner
consistent with the documented DT bindings.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Grant Likely <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
With the UM_SIGNAL alignment fault mode, no siginfo structure is
passed to userspace.
POSIX specifies how siginfo_t should be populated for alignment
faults, so this patch does just that:
* si_signo = SIGBUS
* si_code = BUS_ADRALN
* si_addr = misaligned data address at which access was attempted
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
Reviewed-by: Will Deacon <[email protected]>
Signed-off-by: Russell King <[email protected]>
Currently, it's possible to set the kernel to ignore alignment
faults when changing the alignment fault handling mode at runtime
via /proc/sys/alignment, even though this is undesirable on ARMv6
and above, where it can result in infinite spins where an un-fixed-
up instruction repeatedly faults.
In addition, the kernel clobbers any alignment mode specified on
the command-line if running on ARMv6 or above.
This patch factors out the necessary safety check into a couple of
new helper functions, and checks and modifies the fault handling
mode as appropriate on boot and on writes to /proc/cpu/alignment.
Prior to ARMv6, the behaviour is unchanged.
For ARMv6 and above, the behaviour changes as follows:
* Attempting to ignore faults on ARMv6 results in the mode being
forced to UM_FIXUP instead. A warning is printed if this
happened as a result of a write to /proc/cpu/alignment. The
user's UM_WARN bit (if present) is still honoured.
* An alignment= argument from the kernel command-line is now
honoured, except that the kernel will modify the specified mode
as described above. This is allows modes such as UM_SIGNAL and
UM_WARN to be active immediately from boot, which is useful for
debugging purposes.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
Currently, the documented kernel entry requirements are not
explicit about whether the kernel should be entered in ARM or
Thumb, leading to an ambiguitity about how to enter Thumb-2
kernels. As a result, the kernel is reliant on the zImage
decompressor to enter the kernel proper in the correct instruction
set state.
This patch changes the boot entry protocol for head.S and Image to
be the same as for zImage: in all cases, the kernel is now entered
in ARM.
Documentation/arm/Booting is updated to reflect this new policy.
A different rule will be needed for Cortex-M class CPUs as and when
support for those lands in mainline, since these CPUs don't support
the ARM instruction set at all: a note is added to the effect that
the kernel must be entered in Thumb on such systems.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
Without this patch, xscale_80200_A0_A1 is missing the
icache_flush_all entry, which would result in the wrong functions
being called at run-time.
This patch re-uses xscale_icache_flush_all for
xscale_80200_A0_A1_cache_fns.
Signed-off-by: Dave Martin <[email protected]>
This patch also defines a suitable flush_icache_all implementation
which would otherwise be missing, resulting in a link failure.
Thanks to Nicolas Pitre for suggesting the code for this.
Signed-off-by: Dave Martin <[email protected]>
Signed-off-by: Nicolas Pitre <[email protected]>
Declaring strings in assembler source involves a certain amount of
tedious boilerplate code in order to annotate the resulting symbol
correctly.
Encapsulating this boilerplate in a macro should help to avoid some
duplication and the occasional mistake.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
This patch adds some generic macros to reduce boilerplate when
declaring certain common structures in arch/arm/mm/*.S
Thanks to Russell King for outlining what the
define_processor_functions macro could look like.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
It is easy to mis-maintain the proc_types table such that the
entries become wrongly-sized and misaligned when the kernel is
built in Thumb-2.
This patch adds an assembly-time check which will turn most common
size/alignment mistakes in this table into build failures, to avoid
having to debug the boot-time kernel hang which would happen if the
resulting kernel were actually booted.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
The "Thumb bit" of a symbol is only really meaningful for function
symbols (STT_FUNC).
However, sometimes a branch is relocated against a non-function
symbol; for example, PC-relative branches to anonymous assembler
local symbols are typically fixed up against the start-of-section
symbol, which is not a function symbol. Some inline assembler
generates references of this type, such as fixup code generated by
macros in <asm/uaccess.h>.
The existing relocation code for R_ARM_THM_CALL/R_ARM_THM_JUMP24
interprets this case as an error, because the target symbol appears
to be an ARM symbol; but this is really not the case, since the
target symbol is just a base in these cases. The addend defines
the precise offset to the target location, but since the addend is
encoded in a non-interworking Thumb branch instruction, there is no
explicit Thumb bit in the addend. Because these instructions never
interwork, the implied Thumb bit in the addend is 1, and the
destination is Thumb by definition.
This patch removes the extraneous Thumb bit check for non-function
symbols, enabling modules containing the affected relocation types
to be loaded. No modification to the actual relocation code is
required, since this code does not take bit[0] of the
location->destination offset into account in any case.
Function symbols are always checked for interworking conflicts, as
before.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
Signed-off-by: Russell King <[email protected]>
Drivers which make use of the FIQ interrupt may require the state
of the FIQ mode registers to be preserved across suspend/resume.
Because the FIQ mode registers are not saved and restored
automatically by the kernel, driver authors will need to do the
appropriate save/restore in their own driver suspend/resume
handlers.
Implementing global automatic save/restore of the FIQ state does
not appear appropriate, since this by itself is not sufficient for
FIQ-based drivers to function correctly across suspend/resume in
any case.
This patch adds a brief explanatory note to fiq.h documenting the
requirement placed on driver authors.
Signed-off-by: Dave Martin <[email protected]>
Signed-off-by: Russell King <[email protected]>
* To remove the risk of inconvenient register allocation decisions
by the compiler, these functions are separated out as pure
assembler.
* The apcs frame manipulation code is not applicable for Thumb-2
(and also not easily compatible). Since it's not essential to
have a full frame on these leaf assembler functions, the frame
manipulation is removed, in the interests of simplicity.
* Split up ldm/stm instructions to be compatible with Thumb-2,
as well as avoiding instruction forms deprecated on >= ARMv7.
Signed-off-by: Dave Martin <[email protected]>
Reviewed-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
This patch migrates the implementation of the ptrace interface for
the core integer registers, legacy FPA registers and VFP registers
to use the regsets framework.
As an added bonus, all this stuff gets included in coredumps
at no extra cost. Without this patch, coredumps contained no
VFP state.
Third-party extension register sets (iwmmx, crunch) are not migrated
by this patch, and continue to use the old implementation;
these should be migratable without much extra work.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Russell King <[email protected]>
The VFP registers are not currently included in coredumps,
and there's no existing note type where they can sensibly be
included, so this patch defines a dedicated note type for them.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Russell King <[email protected]>
Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas. As a
result, using these directives in code sections can result in
misaligned data words when building a Thumb-2 kernel
(CONFIG_THUMB2_KERNEL).
This is a Bad Thing, since the ABI permits the compiler to
assume that fundamental types of word size or above are word-
aligned when accessing them from C. If the data is not really
word-aligned, this can cause impaired performance and stray
alignment faults in some circumstances.
In general, the following rules should be applied when using
data word declaration directives inside code sections:
* .quad and .double:
.align 3
* .long, .word, .single, .float:
.align (or .align 2)
* .short:
No explicit alignment required, since Thumb-2
instructions are always 2 or 4 bytes in size.
immediately after an instruction.
Signed-off-by: Dave Martin <[email protected]>
Signed-off-by: Sascha Hauer <[email protected]>
LAKML-Reference: [email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Sascha Hauer <[email protected]>
Various binutils versions can resolve Thumb-2 branches to
locally-defined, preemptible global symbols as short-range "b.n"
branch instructions.
This is a problem, because there's no guarantee the final
destination of the symbol, or any candidate locations for a
trampoline, are within range of the branch. For this reason, the
kernel does not support fixing up the R_ARM_THM_JUMP11 (102)
relocation in modules at all, and it makes little sense to add
support.
The symptom is that the kernel fails with an "unsupported
relocation" error when loading some modules.
Until fixed tools are available, passing
-fno-optimize-sibling-calls to gcc should prevent gcc generating
code which hits this problem, at the cost of a bit of extra runtime
stack usage in some cases.
The problem is described in more detail at:
https://bugs.launchpad.net/binutils-linaro/+bug/725126
Only Thumb-2 kernels are affected.
This patch adds a new CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11 config
option which adds -fno-optimize-sibling-calls to CFLAGS_MODULE
when building a Thumb-2 kernel.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
* Build unconditionally as ARM for correct interoperation with
OMAP firmware.
* Fix an out-of-range ADR when building for ARM.
* Remove deprecated PC-relative stores.
* Add the required ENDPROC() directive for each ENTRY().
* .align before data words.
* Handle non-interworking return from v7_flush_dcache_all.
Signed-off-by: Dave Martin <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
* Build unconditionally as ARM for correct interoperation with
OMAP firmware.
* Remove deprecated PC-relative stores
* Add the required ENDPROC() directive for each ENTRY().
* .align before data words
Signed-off-by: Dave Martin <[email protected]>
Tested-by: Jean Pihet <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
For various reasons, Linux now only officially supports being built
with tools which are new enough to understand the SMC instruction.
Replacing the hand-encoded instructions when the mnemonic also
allows for correct assembly in Thumb-2 (otherwise, the result is
random data in the middle of the code).
The Makefile already ensures that this file is built with a high
enough gcc -march= flag (armv7-a).
Signed-off-by: Dave Martin <[email protected]>
Tested-by: Santosh Shilimkar <[email protected]>
Tested-by: Jean Pihet <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Code marked with ENTRY() also needs a matching ENDPROC() directive,
in order to ensure that the type and instruction set of the
symbol are correctly annotated.
ENDPROC() tags the affected symbol as a function symbol, which will
ensure that link-time fixups don't accidentally switch to the
wrong instruction set.
Signed-off-by: Dave Martin <[email protected]>
Tested-by: Santosh Shilimkar <[email protected]>
Acked-by: Santosh Shilimkar <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
For CONFIG_THUMB2_KERNEL, the existing definition of do_wfi() will
insert invalid code into the instruction stream.
Any assembler which can assemble Thumb-2 is guaranteed to accept
the "wfi" mnemonic, so for the Thumb-2 case, just use the mnemonic.
The ARM case is left as-is.
Signed-off-by: Dave Martin <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Loading Thumb-2 modules into an ARM kernel or vice-versa isn't
guaranteed to work safely, since the kernel is not interworking-
aware everywhere.
This patch adds "thumb2" to the module vermagic when
CONFIG_THUMB2_KERNEL is enabled, to help avoid accidental loading
of modules into the wrong kernel.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
The kernel doesn't officially need to interwork, but using BX
wherever appropriate will help educate people into good assembler
coding habits.
BX is appropriate here because this code is predicated on
__LINUX_ARM_ARCH__ >= 6
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
rmk says: "You might as well make OABI_COMPAT depend on !THUMB2_KERNEL.
OABI userland is useless without FPA support."
nwfpe doesn't work with Thumb-2 anyway and will probably never get
ported, so I can't argue with that.
This patch implements the dependency change.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
The content for ALT_SMP() in the definition of WFE() expands to 6
bytes (IT cc ; WFEcc.W), which breaks the assumptions of the fixup
code, leading to lockups when the affected code gets run.
This patch works around the problem by explicitly using an
IT + WFEcc.N pair.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Russell King <[email protected]>
In low-level board support code, there is sometimes a need to
copy a function body to another location at run-time.
A straightforward call to memcpy doesn't work in Thumb-2,
because bit 0 of external Thumb function symbols is set to 1,
indicating that the function is Thumb. Without corrective
measures, this will cause an off-by-one copy, and the copy
may be called using the wrong instruction set.
This patch adds an fncpy() macro to help with such copies.
Particular care is needed, because C doesn't guarantee any
defined behaviour when casting a function pointer to any other
type. This has been observed to lead to strange optimisation
side-effects when doing the arithmetic which is required in
order to copy/move function bodies correctly in Thumb-2.
Thanks to Russell King and Nicolas Pitre for their input
on this patch.
Signed-off-by: Dave Martin <[email protected]>
Tested-by: Jean Pihet <[email protected]>
Tested-by: Tony Lindgren <[email protected]>
Tested-by: Kevin Hilman <[email protected]>
Signed-off-by: Russell King <[email protected]>
Commit d30e45e (ARM: pgtable: switch order of Linux vs hardware page tables)
introduced a pre-increment addressing offset which is out of range for
Thumb-2. Thumb-2 only permits offsets <256. So split the intruction in
two for Thumb-2.
Signed-off-by: Dave Martin <[email protected]>
Signed-off-by: Russell King <[email protected]>
* __fixup_smp_on_up has been modified with support for the
THUMB2_KERNEL case. For THUMB2_KERNEL only, fixups are split
into halfwords in case of misalignment, since we can't rely on
unaligned accesses working before turning the MMU on.
No attempt is made to optimise the aligned case, since the
number of fixups is typically small, and it seems best to keep
the code as simple as possible.
* Add a rotate in the fixup_smp code in order to support
CPU_BIG_ENDIAN, as suggested by Nicolas Pitre.
* Add an assembly-time sanity-check to ALT_UP() to ensure that
the content really is the right size (4 bytes).
(No check is done for ALT_SMP(). Possibly, this could be fixed
by splitting the two uses ot ALT_SMP() (ALT_SMP...SMP_UP versus
ALT_SMP...SMP_UP_B) into two macros. In the first case,
ALT_SMP needs to expand to >= 4 bytes, not == 4.)
* smp_mpidr.h (which implements ALT_SMP()/ALT_UP() manually due
to macro limitations) has not been modified: the affected
instruction (mov) has no 16-bit encoding, so the correct
instruction size is satisfied in this case.
* A "mode" parameter has been added to smp_dmb:
smp_dmb arm @ assumes 4-byte instructions (for ARM code, e.g. kuser)
smp_dmb @ uses W() to ensure 4-byte instructions for ALT_SMP()
This avoids assembly failures due to use of W() inside smp_dmb,
when assembling pure-ARM code in the vectors page.
There might be a better way to achieve this.
* Kconfig: make SMP_ON_UP depend on
(!THUMB2_KERNEL || !BIG_ENDIAN) i.e., THUMB2_KERNEL is now
supported, but only if !BIG_ENDIAN (The fixup code for Thumb-2
currently assumes little-endian order.)
Tested using a single generic realview kernel on:
ARM RealView PB-A8 (CONFIG_THUMB2_KERNEL={n,y})
ARM RealView PBX-A9 (SMP)
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
Because the nwfpe support is unlikely to be used on new platforms
and requires CONFIG_OABI_COMPAT, which is not generally used with
ARMv7+, we shouldn't expect to build nwfpe support into a Thumb-2
kernel.
At present, nwfpe contains assembly code which isn't Thumb-2
compatible, and for now it doesn't appear useful to port this
code.
All ARMv7-A/R platforms necessarily have VFPv3 hardware floating-
point natively, making emulation unnecessary.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Acked-by: Santosh Shilimkar <[email protected]>
Signed-off-by: Russell King <[email protected]>
This makes sense, because Thumb-2 code can't execute on plain
ARMv6 processors.
This will avoid accidentally configuring a broken kernel where the
config otherwise would allow multiple architecture versions to
coexist in the same kernel.
Not adding !CPU_V5 etc., because the chance of anyone trying to
put v5 and v7 in the same kernel is low, and I'm not aware of
any mach which can do this. These could be added later if it
matters.
Note that the rules may need to be refined if support for the
ARM1156J(F)-S processor is later added to the kernel, since this
processor supports the rare ARMv6T2 extensions, which add support
for Thumb-2 and a few other ARMv7 features.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Acked-by: Santosh Shilimkar <[email protected]>
Signed-off-by: Russell King <[email protected]>
The existing code invokes the syscall with rubbish in r7,
due to what looks like an incorrect literal load idiom.
Reviewed-by: Will Deacon <[email protected]>
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
Signed-off-by: Russell King <[email protected]>
* Fix kexec build failure with CONFIG_THUMB2_KERNEL.
* Avoids deprecated/forbidden sp and pc usage in for ARMv7
onwards, retaining compatibility with older architecture
versions.
* The pc value saved to newregs is now aligned on a predictable
instruction boundary.
(stmia { ... pc } or str pc has implementation-defined results
in most versions of the ARM architecutre, and is prohibited
(unpredictable) in Thumb-2.)
* Switch to named inline asm arguments (else I get readily
confused ...)
The resulting code should be compatible with all architecture
versions >= v3, with or without CONFIG_THUMB2_KERNEL.
Reviewed-by: Will Deacon <[email protected]>
Tested-by: Mika Westerberg <[email protected]>
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
Signed-off-by: Russell King <[email protected]>
Currently, the inline asm is passed &newregs->ARM_r0 as in input,
when modifying multiple fields of newregs.
It's plausible to assume that GCC will assume newregs->ARM_r0 is
modified when passed the address, but unfortunately this assumption
is incorrect.
Also, GCC has no way to guess that the other ARM_r* fields are
modified without the addition of a "memory" clobber.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Russell King <[email protected]>
Currently, the kprobes implementation for ARM only supports the ARM
instruction set, so it only works if CONFIG_THUMB2_KERNEL is not
enabled.
Until kprobes is updated to work with Thumb-2, turning it on will
cause horrible things to happen, so this patch disables it for now.
Signed-off-by: Dave Martin <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
Dave Martin