ARM: vfp: Use undef hook for handling VFP exceptions

Now that the VFP support code has been reimplemented as a C function
that takes a struct pt_regs pointer and an opcode, we can use the
existing u

ARM: vfp: Use undef hook for handling VFP exceptions

Now that the VFP support code has been reimplemented as a C function
that takes a struct pt_regs pointer and an opcode, we can use the
existing undef_hook framework to deal with undef exceptions triggered by
VFP instructions instead of having special handling in assembler.

Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>

show more ...

ARM: 8989/1: use .fpu assembler directives instead of assembler arguments

Explicit FPU selection has been introduced in commit 1a6be26d5b1a
("[ARM] Enable VFP to be built when non-VFP capable CPUs a

ARM: 8989/1: use .fpu assembler directives instead of assembler arguments

Explicit FPU selection has been introduced in commit 1a6be26d5b1a
("[ARM] Enable VFP to be built when non-VFP capable CPUs are selected")
to make use of assembler mnemonics for VFP instructions.

However, clang currently does not support passing assembler flags
like this and errors out with:
clang-10: error: the clang compiler does not support '-Wa,-mfpu=softvfp+vfp'

Make use of the .fpu assembler directives to select the floating point
hardware selectively. Also use the new unified assembler language
mnemonics. This allows to build these procedures with Clang.

Link: https://github.com/ClangBuiltLinux/linux/issues/762

Signed-off-by: Stefan Agner <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

treewide: Add SPDX license identifier - Makefile/Kconfig

Add SPDX license identifiers to all Make/Kconfig files which:

- Have no license information of any form

These files fall under the project

treewide: Add SPDX license identifier - Makefile/Kconfig

Add SPDX license identifiers to all Make/Kconfig files which:

- Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

GPL-2.0-only

Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

ARM: 8782/1: vfp: clean up arch/arm/vfp/Makefile

Since commit 799c43415442 ("kbuild: thin archives make default for
all archs"), $(AR) is used instead of $(LD) to combine object files.

The followin

ARM: 8782/1: vfp: clean up arch/arm/vfp/Makefile

Since commit 799c43415442 ("kbuild: thin archives make default for
all archs"), $(AR) is used instead of $(LD) to combine object files.

The following code in arch/arm/vfp/Makefile:

LDFLAGS +=--no-warn-mismatch

... is no longer used.

Also, arch/arm/Makefile already guards arch/arm/vfp/ by a boolean
symbol, CONFIG_VFP, like this:

core-$(CONFIG_VFP) += arch/arm/vfp/

So, $(CONFIG_VFP) is always evaluated to y in arch/arm/vfp/Makefile.
There is no point to use pseudo object, vfp.o, which never becomes
a module. Add all objects to obj-y directly.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

ARM: vfp: use -mfloat-abi=soft to build vfp

Distros are starting to ship with toolchains defaulting to
hardfloat. Using such a compiler to build the kernel fails
in the VFP directory with

arch/arm/

ARM: vfp: use -mfloat-abi=soft to build vfp

Distros are starting to ship with toolchains defaulting to
hardfloat. Using such a compiler to build the kernel fails
in the VFP directory with

arch/arm/vfp/entry.S:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP

Adding -mfloat-abi=soft to the gcc command line fixes this.

Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

arm: change to new flag variables

Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.

Signed-off-by: matt mooney <[email protected]>
Acked-by: WANG Cong <[email protected]>

arm: change to new flag variables

Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.

Signed-off-by: matt mooney <[email protected]>
Acked-by: WANG Cong <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

kbuild: enable 'make AFLAGS=...' to add additional options to AS

The variable AFLAGS is a wellknown variable and the usage by
kbuild may result in unexpected behaviour.
On top of that several people

kbuild: enable 'make AFLAGS=...' to add additional options to AS

The variable AFLAGS is a wellknown variable and the usage by
kbuild may result in unexpected behaviour.
On top of that several people over time has asked for a way to
pass in additional flags to gcc.

This patch replace use of AFLAGS with KBUILD_AFLAGS all over
the tree.

Patch was tested on following architectures:
alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390

Signed-off-by: Sam Ravnborg <[email protected]>

show more ...

[ARM] Enable VFP to be built when non-VFP capable CPUs are selected

Since we pass flags to the compiler to control code generation based
on the least capable selected CPU, if we want to include VFP

[ARM] Enable VFP to be built when non-VFP capable CPUs are selected

Since we pass flags to the compiler to control code generation based
on the least capable selected CPU, if we want to include VFP support,
we must tweak the assembler flags to allow the VFP instructions.
Moreover, we must not use the mrrc/mcrr versions since these will not
be recognised by the assembler.

We do not convert all instructions to the VFP-equivalent (yet) since
binutils appears to barf on "fmrx rn, fpinst" and doesn't provide any
other way (other than using the mrc equivalent) to encode this
instruction - which is rather a problem when you have a VFP
implementation which requires these instructions.

Signed-off-by: Russell King <[email protected]>

show more ...

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!

show more ...