We cannot detect clang before including the arch Makefile, because that
can set the default cross compiler. We also cannot detect clang after
including the arch Makefile, because powerpc wants to know about clang.
Solve this by using an deferred variable. This costs us a few shell
invocations, but this is only a constant number.
Reported-by: NBehan Webster <behanw@converseincode.com>
Reported-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NMichal Marek <mmarek@suse.com>

We have code to choose between several options, eg. -mabi=elfv2 vs
-mcall-aixdesc, and -mcmodel=medium vs -mminimal-toc. But these are all
GCC specific, so use cc-option on all of them.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

We added -mno-strict-align in commit f036b368 (powerpc: Work around little
endian gcc bug) to fix gcc bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134

Clang doesn't understand it. We need to use a conditional because we can't use the
simpler call cc-option here.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

These options are not recognised on LLVM, so use call cc-option to check
for support.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

Rather than continuing to maintain a copy of pseries_defconfig with
CONFIG_CPU_LITTLE_ENDIAN enabled, use the generic merge_config script
and use an le.config to enable little endian on top of pseries_defconfig
without the need for a duplicated _defconfig file.

This method will require less maintenance in the future and will ensure
that both 'defconfigs' are always in sync.

It is worth noting that the seemingly more simple approach of:

  pseries_le_defconfig: pseries_defconfig
  	$(Q)$(MAKE) le.config

Will not work when building using O=builddir.

The obvious fix to that:

  pseries_le_defconfig:
  	$(Q)$(MAKE) -f $(srctree)/Makefile pseries_defconfig le.config

Also does not work. This is because if we have for example:

config FOO
	depends on CPU_BIG_ENDIAN
	select BAR

Then BAR will be enabled by the first call to kconfig (via
pseries_defconfig), and then will remain enabled after we merge
le.config, even though FOO will have been turned off.

The solution is to ensure to only invoke the kconfig logic once, after
we have merged all the config fragments. This ensures nothing is
select'ed on that should then be disabled by the later merged configs.
This is done through the explicit call to make olddefconfig
Signed-off-by: NCyril Bur <cyrilbur@gmail.com>
Reviewed-by: NSamuel Mendoza-Jonas <sam.mj@au1.ibm.com>
[mpe: Massage change log, fix white space and use ARCH not SRCARCH]
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

There is a bug in binutils 2.24 which causes miscompilation if we're
building little endian and using weak symbols (which the kernel does).

It is fixed in binutils commit 57fa7b8c7e59 "Correct elf_merge_st_other
arguments for weak symbols", which is in binutils 2.25 and has been
backported to the binutils 2.24 branch and has been picked up by most
distros it seems.

However if we're running stock 2.24 (no extra version) then the bug is
present, so check for that and bail.
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

We have several checks for bad gcc versions in our Makefile. These don't
apply if we're building with clang, so skip them in that case.

The obvious check would be for ${COMPILER} = "gcc", but because of the
way the logic in the top level Makefile conditionally sets COMPILER,
it's possible that we're building with gcc but COMPILER was not set.

So instead check for ${COMPILER} != "clang", which we know is currently
the only other possibility.
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

This runs a bit faster and removes another use of perl from
the kernel build.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-By: NTony Breeds <tony@bakeyournoodle.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

The macros cc-version, cc-fullversion and ld-version take no argument.
It is not necessary to add $(call ...) to invoke them.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Helge Deller <deller@gmx.de> [parisc]
Signed-off-by: NMichal Marek <mmarek@suse.cz>

This allows the user to build a kernel targeted at POWER8
(ie gcc -mcpu=power8).
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

With binutils 2.24, various 64 bit builds fail with relocation errors
such as

arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
	(.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI
	against symbol `interrupt_base_book3e' defined in .text section
	in arch/powerpc/kernel/built-in.o
arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
	(.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI
	against symbol `interrupt_end_book3e' defined in .text section
	in arch/powerpc/kernel/built-in.o

The assembler maintainer says:

 I changed the ABI, something that had to be done but unfortunately
 happens to break the booke kernel code.  When building up a 64-bit
 value with lis, ori, shl, oris, ori or similar sequences, you now
 should use @high and @higha in place of @h and @ha.  @h and @ha
 (and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA)
 now report overflow if the value is out of 32-bit signed range.
 ie. @h and @ha assume you're building a 32-bit value. This is needed
 to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h
 and @toc@ha expressions, and for consistency I did the same for all
 other @h and @ha relocs.

Replacing @h with @high in one strategic location fixes the relocation
errors. This has to be done conditionally since the assembler either
supports @h or @high but not both.

Cc: <stable@vger.kernel.org>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This patch adds an option to enable a work around for an icache bug on
476 that can cause execution of stale instructions when falling
through pages (IBM errata #46). It requires a recent version of
binutils which supports the --ppc476-workaround option.

The work around enables the appropriate linker options and ensures
that all module output sections are aligned to 4K page boundaries. The
work around is only required when building modules.
Signed-off-by: NAlistair Popple <alistair@popple.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Build the little endian ppc64 kernel with ABIv2 if the toolchain
supports it. We can identify an ABIv2 capable toolchain by the
-mabi=elfv2 compiler flag.
Signed-off-by: NAnton Blanchard <anton@samba.org>

We avoid ABIv2 when building c files since commit b2ca8c89 (powerpc:
Don't use ELFv2 ABI to build the kernel). Do the same for assembly
files.
Signed-off-by: NAnton Blanchard <anton@samba.org>

When building modules with a native le toolchain the linker will
generate R_PPC64_TOCSAVE relocations when it's safe to omit saving r2 on
a plt call.  This isn't helpful in the conext of a kernel module and the
kernel will fail to load those modules with an error like:
	nf_conntrack: Unknown ADD relocation: 109

This patch tells the linker to avoid createing R_PPC64_TOCSAVE
relocations allowing modules to load.
Signed-off-by: NTony Breeds <tony@bakeyournoodle.com>
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Currently if I cross build TAGS or cscope from x86 I get this:
  % make ARCH=powerpc TAGS
  gcc-4.8.real: error: unrecognized command line option ‘-mbig-endian’
  GEN     TAGS
  %

I'm not setting CROSS_COMPILE= as logically I shouldn't need to and I
haven't needed to in the past when building TAGS or cscope.  Also, the
above completess correct as the error is not fatal to the build.

This was caused by:
    commit d72b0801
    Author: Ian Munsie <imunsie@au1.ibm.com>
    powerpc: Add ability to build little endian kernels

The below fixes this by testing for the -mbig-endian option before
adding it.

I've not done the same thing in the little endian case as if
-mlittle-endian doesn't exist, we probably want to fail quickly as you
probably have an old big endian compiler.
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

If CONFIG_ALTIVEC is enabled for CoreNet64, and if we also
select CONFIG_E{5,6}500_CPU this may introduce -mcpu=e500mc64
into $CFLAGS. But Altivec option not allowed with e500mc64,
then some compiling errors occur like this:

      CC      arch/powerpc/lib/xor_vmx.o
    arch/powerpc/lib/xor_vmx.c:1:0: error: AltiVec not supported in this target
    make[1]: *** [arch/powerpc/lib/xor_vmx.o] Error 1
    make: *** [arch/powerpc/lib] Error 2

So we should restrict e500mc64 in altivec scenario.
Signed-off-by: NTiejun Chen <tiejun.chen@windriver.com>
Signed-off-by: NScott Wood <scottwood@freescale.com>

The kernel doesn't build correctly using the ELFv2 ABI.  This patch
ensures that the ELFv1 ABI is used when building a kernel with an
ELFv2 enabled compiler.
Signed-off-by: NAlistair Popple <alistair@popple.id.au>
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Temporarily work around an ICE we are seeing while building
in little endian mode:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This patch allows the kbuild system to successfully compile a kernel
for the little endian PowerPC64 architecture. A subsequent patch
will add the CONFIG_CPU_LITTLE_ENDIAN kernel config option which
must be set to build such a kernel.

If cross compiling, CROSS_COMPILE must point to a suitable toolchain
(compiled for the powerpc64le-linux and powerpcle-linux targets).
Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

We need to distinguish between big endian and little endian
environments, so fix uname to return the right thing.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Unlike 64-bit, we don't currently support multiplatform between e500
and non-e500, so the -mcpu is not configurable at this time.

-msoft-float is specified when testing for -mcpu=8540 because otherwise
some older toolchains will fail with "error: E500 and FPRs not
supported".
Signed-off-by: NScott Wood <scottwood@freescale.com>

By default use -mcpu=powerpc64 rather than -mtune=power7

Add options for e5500/e6500, with fallbacks for older compilers.

Hide the POWER cpu options in booke configs.
Signed-off-by: NScott Wood <scottwood@freescale.com>

This caused lwsync to be converted to sync on 64-bit (on 32-bit lwsync
is generated at runtime, and so wasn't affected).  Not using lwsync
caused a significant slowdown on certain workloads.

Setting this flag for any e500-enabled build is also not friendly to
multiplatform kernels.
Signed-off-by: NScott Wood <scottwood@freescale.com>

This reverts commit c8db32c8.

The commit breaks the build of all my 64-bit embedded configs. It
looks like gcc-4.7.3 doesn't know about e5500. Additionally it
incorrectly does -mcpu=e5500 on a config that has both e5500 and A2
support enabled.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
---

If CONFIG_E500 is enabled, the compilation flags are updated
specifying the target core -mcpu=e5500/e500mc/8540
Also remove -Wa,-me500, being incompatible with -mcpu=e5500/e6500
The assembler option is redundant if the -mcpu= flag is set.
The patch fixes the kernel compilation problem for e5500/e6500
when using gcc option -mcpu=e5500/e6500.
Signed-off-by: NCatalin Udma <catalin.udma@freescale.com>
Signed-off-by: NScott Wood <scottwood@freescale.com>

powerpc: Avoid load of static chain register when calling nested functions through a pointer on 64bit

The ppc64 ABI has a static chain register (r11) which is only used
when calling nested functions through a pointer. Considering that
we take a dim view of nested functions in the kernel, we have a lot
of unnecessary overhead here.

gcc 4.7 has an option to disable loading of r11 so lets use it.

If hell freezes over and hipsters manage to litter the kernel
with nested functions, gcc will give us an error message and
won't simply compile bad code:

    You cannot take the address of a nested function if you use
    the -mno-pointers-to-nested-functions option.

Furthermore our kernel module trampolines don't setup the static
chain register so adding this option and forcing gcc to error out
makes even more sense.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Finally remove the two level TOC and build with -mcmodel=medium.

Unfortunately we can't build modules with -mcmodel=medium due to
the tricks the kernel module loader plays with percpu data:

# -mcmodel=medium breaks modules because it uses 32bit offsets from
# the TOC pointer to create pointers where possible. Pointers into the
# percpu data area are created by this method.
#
# The kernel module loader relocates the percpu data section from the
# original location (starting with 0xd...) to somewhere in the base
# kernel percpu data space (starting with 0xc...). We need a full
# 64bit relocation for this to work, hence -mcmodel=large.

On older kernels we fall back to the two level TOC (-mminimal-toc)
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The ppc64 kernel can get loaded at any address which means
our very early init code in prom_init.c must be relocatable. We do
this with a pretty nasty RELOC() macro that we wrap accesses of
variables with. It is very fragile and sometimes we forget to add a
RELOC() to an uncommon path or sometimes a compiler change breaks it.

32bit has a much more elegant solution where we build prom_init.c
with -mrelocatable and then process the relocations manually.
Unfortunately we can't do the equivalent on 64bit and we would
have to build the entire kernel relocatable (-pie), resulting in a
large increase in kernel footprint (megabytes of relocation data).
The relocation data will be marked __initdata but it still creates
more pressure on our already tight memory layout at boot.

Alan Modra pointed out that the 64bit ABI is relocatable even
if we don't build with -pie, we just need to relocate the TOC.
This patch implements that idea and relocates the TOC entries of
prom_init.c. An added bonus is there are very few relocations to
process which helps keep boot times on simulators down.

gcc does not put 64bit integer constants into the TOC but to be
safe we may want a build time script which passes through the
prom_init.c TOC entries to make sure everything looks reasonable.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This patch adds a crypto driver which provides a powerpc accelerated
implementation of SHA-1, accelerated in that it is written in asm.

Original patch by Paul, minor fixups for upstream by moi.

Lightly tested on 64-bit with the test program here:

 http://michael.ellerman.id.au/files/junkcode/sha1test.c

Seems to work, and is "not slower" than the generic version.

Needs testing on 32-bit.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Fixes this following:

$ make distclean; make corenet32_smp_defconfig; make p4080ds.dtb
  CLEAN   arch/powerpc/boot
  CLEAN   scripts/basic
  CLEAN   scripts/dtc
  CLEAN   scripts/genksyms
  CLEAN   scripts/kconfig
  CLEAN   scripts/mod
  CLEAN   scripts
  CLEAN   include/config include/generated
  CLEAN   .config
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.lex.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
  DTC     arch/powerpc/boot/p4080ds.dtb
/bin/sh: /local/home/mattsm/git/linux/scripts/dtc/dtc: No such file or directory
make[1]: *** [arch/powerpc/boot/p4080ds.dtb] Error 1
make: *** [p4080ds.dtb] Error 2
Signed-off-by: NMatthew McClintock <msm@freescale.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

When the nx driver was pulled, the Makefile that actually
builds it is arch/powerpc/Makefile. This is unnatural.

This patch moves the line that builds the nx driver from
arch/powerpc/Makefile to drivers/crypto/Makefile where it
belongs.
Signed-off-by: NSeth Jennings <sjenning@linux.vnet.ibm.com>
Acked-by: NKent Yoder <key@linux.vnet.ibm.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

These files support configuring and building the nx device driver.
Signed-off-by: NKent Yoder <key@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Add a menu to select various 64-bit CPU targets for gcc. We
default to -mtune=power7 and if gcc doesn't understand that we
fallback to -mtune=power4.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Now we require gcc 4.0 on 64-bit we can remove the pre gcc 4.0
-maltivec workaround.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Older versions of gcc had issues with using -maltivec together with
-mcpu of a non altivec capable CPU. We work around it by specifying
-mcpu=970, but the logic is complicated.

In preparation for adding more -mcpu targets, remove the workaround
and just require gcc 4.0 for 64-bit builds.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The perf code has grown a lot since it started, and is big enough to
warrant its own subdirectory. For reference it's ~60% bigger than the
oprofile code. It declutters the kernel directory, makes it simpler to
grep for "just perf stuff", and allows us to shorten some filenames.

While we're at it, make it more obvious that we have two implementations
of the core perf logic. One for (roughly) Book3S CPUs, which was the
original implementation, and the other for Freescale embedded CPUs.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The following patch implements the dynamic relocation processing for
PPC32 kernel. relocate() accepts the target virtual address and relocates
 the kernel image to the same.

Currently the following relocation types are handled :

	R_PPC_RELATIVE
	R_PPC_ADDR16_LO
	R_PPC_ADDR16_HI
	R_PPC_ADDR16_HA

The last 3 relocations in the above list depends on value of Symbol indexed
whose index is encoded in the Relocation entry. Hence we need the Symbol
Table for processing such relocations.

Note: The GNU ld for ppc32 produces buggy relocations for relocation types
that depend on symbols. The value of the symbols with STB_LOCAL scope
should be assumed to be zero. - Alan Modra
Signed-off-by: NSuzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: NJosh Poimboeuf <jpoimboe@linux.vnet.ibm.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Alan Modra <amodra@au1.ibm.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Signed-off-by: NJosh Boyer <jwboyer@gmail.com>

So I've had one of these for a while and it looks like the vendor never
bothered submitting the support upstream.

This adds it using ppc40x_simple and provides a device-tree.

There are some changes to the boot wrapper because the way u-boot works
on this thing, it seems to expect a multipart image with the kernel,
initrd and dtb in it.

The USB support is missing as it needs the yet unmerged driver for
the DWC OTG part and the GPIOs may need further definition in the dts.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

In lieu of having multiple similiar lines, we can just have one
generic cpu-as line for CONFIG_ALTIVEC
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>