linux.git/arch/powerpc/Makefile, branch v4.17

powerpc/64s: Add POWER9 CPU type selection

2018-04-01T12:15:32+00:00

Signed-off-by: Nicholas Piggin 
Signed-off-by: Michael Ellerman

powerpc/64: Add GENERIC_CPU support for little endian

2018-04-01T11:52:52+00:00

Add GENERIC_CPU support for little-endian rather than using POWER8
specific selection for POWER9 and above.

Restrict GENERIC_CPU to POWER8 and above on little endian.

Signed-off-by: Nicholas Piggin 
[mpe: Duplicate GENERIC_CPU to avoid a kbuild warning about the prompt
      being redefined. Spell out that GENERIC means >= POWER4 for BE.]
Signed-off-by: Michael Ellerman

powerpc/64s: Remove POWER4 support

2018-03-31T13:47:50+00:00

POWER4 has been broken since at least the change 49d09bf2a6
("powerpc/64s: Optimise MSR handling in exception handling"), which
requires mtmsrd L=1 support. This was introduced in ISA v2.01, and
POWER4 supports ISA v2.00.

Signed-off-by: Nicholas Piggin 
Signed-off-by: Michael Ellerman

powerpc/64s: Set assembler machine type to POWER4

2018-03-31T13:47:49+00:00

Rather than override the machine type in .S code (which can hide wrong
or ambiguous code generation for the target), set the type to power4
for all assembly.

This also means we need to be careful not to build power4-only code
when we're not building for Book3S, such as the "power7" versions of
copyuser/page/memcpy.

Signed-off-by: Nicholas Piggin 
[mpe: Fix Book3E build, don't build the "power7" variants for non-Book3S]
Signed-off-by: Michael Ellerman

powerpc: Keep const vars out of writable .sdata

2018-03-05T22:21:21+00:00

Newer gcc will support "-mno-readonly-in-sdata"[1], which makes sure that
the optimization on PPC32 for variables getting moved into the .sdata
section will not apply to const variables (which must be in .rodata).

This was originally noticed in mm/rodata_test.c when rodata_test_data
was not static:

c0695034 g     O .data	00000004 rodata_test_data

After this patch with an updated compiler, this is correctly in .rodata.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82411

Reported-by: Christophe Leroy 
Signed-off-by: Segher Boessenkool 
Signed-off-by: Kees Cook 
Signed-off-by: Michael Ellerman

powerpc/modules: Fix alignment of .toc section in kernel modules

2017-12-11T02:03:35+00:00

powerpc64 gcc can generate code that offsets an address, to access
part of an object in memory. If the address is a -mcmodel=medium toc
pointer relative address then code like the following is possible.

  addis r9,r2,var@toc@ha
  ld r3,var@toc@l(r9)
  ld r4,(var+8)@toc@l(r9)

This works fine so long as var is naturally aligned, *and* r2 is
sufficiently aligned. If not, there is a possibility that the offset
added to access var+8 wraps over a n*64k+32k boundary. Modules don't
have any guarantee that r2 is sufficiently aligned. Moreover, code
generated by older compilers generates a .toc section with 2**0
alignment, which can result in relocation failures at module load time
even without the wrap problem.

Thus, this patch links modules with an aligned .toc section (Makefile
and module.lds changes), and forces alignment for out of tree modules
or those without a .toc section (module_64.c changes).

Signed-off-by: Alan Modra 
[desnesn: updated patch to apply to powerpc-next kernel v4.15 ]
Signed-off-by: Desnes A. Nunes do Rosario 
[mpe: Fix out-of-tree build, swap -256 for ~0xff, reflow comment]
Signed-off-by: Michael Ellerman

Merge branch 'fixes' into next

2017-08-23T12:20:10+00:00

There's a non-trivial dependency between some commits we want to put in
next and the KVM prefetch work around that went into fixes. So merge
fixes into next.

powerpc/8xx: Getting rid of remaining use of CONFIG_8xx

2017-08-10T13:32:12+00:00

Two config options exist to define powerpc MPC8xx:
* CONFIG_PPC_8xx
* CONFIG_8xx

arch/powerpc/platforms/Kconfig.cputype has contained the following
comment about CONFIG_8xx item for some years:
"# this is temp to handle compat with arch=ppc"

arch/powerpc is now the only place with remaining use of
CONFIG_8xx: get rid of them.

Signed-off-by: Christophe Leroy 
Signed-off-by: Michael Ellerman

powerpc/configs: Add a powernv_be_defconfig

2017-07-31T06:56:37+00:00

Although pretty much everyone using powernv is running little endian,
we should still test we can build for big endian. So add a
powernv_be_defconfig, which is autogenerated by flipping the endian
symbol in powernv_defconfig.

Signed-off-by: Michael Ellerman 
Reviewed-by: Cyril Bur

powerpc/Makefile: Fix ld version check with 64-bit LE-only toolchain

2017-07-26T06:41:54+00:00

In commit efe0160cfd40 ("powerpc/64: Linker on-demand sfpr functions
for modules"), we added an ld version check early in the powerpc
top-level Makefile.

Because the Makefile runs before the kernel config is setup, the
checks for CONFIG_CPU_LITTLE_ENDIAN etc. all take the default case. So
we end up configuring ld for 32-bit big endian.

That would be OK, except that for historical (or perhaps no) reason,
we use 'override LD' to add the endian flags to the LD variable
itself, rather than the normal approach of adding them to LDFLAGS.

The end result is that when we check the ld version we run it as:

  $(CROSS_COMPILE)ld -EB -m elf32ppc --version

This often works, unless you are using a 64-bit only and/or little
endian only, toolchain. In which case you see something like:

  $ make defconfig
  powerpc64le-linux-ld: unrecognised emulation mode: elf32ppc
  Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim
  /bin/sh: 1: [: -ge: unexpected operator

The proper fix is to stop using 'override LD', but that will require a
fair bit of testing. Instead we can fix it for now just by reordering
the Makefile to do the version check earlier.

Fixes: efe0160cfd40 ("powerpc/64: Linker on-demand sfpr functions for modules")
Signed-off-by: Michael Ellerman