powerpc/configs/64s: Enable CHECKPOINT_RESTORE

Most distros enable this.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230414132415.821564-13-mpe@ellerman.id.au

powerpc/configs/64s: Enable common CGROUP & related options

Distros enable these options.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230414132415.821564-12-mpe@ellerman.id.au

powerpc/configs/64s: Enable NO_HZ_FULL

At least Fedora & SUSE enable it.

VIRT_CPU_ACCOUNTING_GEN is selected so no longer needs to be in the
defconfig.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230414132415.821564-11-mpe@ellerman.id.au

powerpc/configs/64s: Enable common accounting options

These options are enabled by most distros.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230414132415.821564-10-mpe@ellerman.id.au

powerpc/configs/64s: Enable AUDIT

Essentially all distros enable it.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230414132415.821564-9-mpe@ellerman.id.au

powerpc/configs/64s: Enable PREEMPT_VOLUNTARY

Traditionally on powerpc servers PREEMPT_NONE was used, but these days
multiple distros are building with PREEMPT_VOLUNTARY - Ubuntu, Fedora &
CentOS all enable it.

So update the upstream config to reflect that, and get test coverage
before code hits the distros.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230414132415.821564-8-mpe@ellerman.id.au

powerpc/configs/64s: Select ARCH_WANT_DEFAULT_BPF_JIT

Tell the generic BPF code that the JIT should be enabled by default,
rather than the interpreter. Most distros use CONFIG_BPF_JIT_ALWAYS_ON=y
anyway, so this just updates upstream to more closely match that.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230414132415.821564-7-mpe@ellerman.id.au

powerpc/configs/64s: Add secure boot options to defconfig

Add the numerous options required to get secure boot enabled.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230414132415.821564-6-mpe@ellerman.id.au

powerpc/configs/64s: Enable PAPR_SCM

This is a powerpc specific driver so add the symbols required to enable
it so it gets some build/boot test coverage.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230414132415.821564-5-mpe@ellerman.id.au

powerpc/configs/6s: Drop obsolete crypto ALGs

These algorithms were marked obsolete in commit 1674aea5f080 ("crypto:
Kconfig - mark unused ciphers as obsolete").

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230414132415.821564-4-mpe@ellerman.id.au

powerpc/configs/64s: Drop IPV6 which is default y

Since commit de551f2eb22a ("net: Build IPv6 into kernel by default"),
IPV6 is default y.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230414132415.821564-3-mpe@ellerman.id.au

powerpc/configs/64s: Drop SPLPAR which is default y

SPLPAR is default y since commit 20c0e8269e9d ("powerpc/pseries:
Implement paravirt qspinlocks for SPLPAR"), so doesn't need to be in the
defconfig.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230414132415.821564-2-mpe@ellerman.id.au

powerpc/configs/64s: Update defconfig for symbol movement

Update ppc64_defconfig to account for symbols moving around, no actual
changes.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230414132415.821564-1-mpe@ellerman.id.au

powerpc/Makefile: Add generated defconfigs to help output

Currently none of the generated defconfigs appear in the help output,
because the help text discovers defconfigs by looking for actual files
named "*_defconfig".

Collect the generated defconfig names into a variable and then print
those out in archhelp.

Output looks like eg:

  pseries_le_defconfig        - Build for pseries_le
  ppc64le_defconfig           - Build for ppc64le
  ppc64le_guest_defconfig     - Build for ppc64le_guest
  ...
  ppc64_randconfig            - Build for ppc64_randconfig

  adder875_defconfig          - Build for adder875
  amigaone_defconfig          - Build for amigaone

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[mpe: Fix PHONY bug which broke in-tree build, thanks rmclure]
Link: https://msgid.link/20230329072334.2023357-2-mpe@ellerman.id.au

powerpc/Makefile: Don't prefix archhelp commands with "@"

It's not necessary to prefix every command in archhelp with "@" (to
suppress echoing the command), because that is done by the top level
Makefile when it evaluates archhelp.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230329072334.2023357-1-mpe@ellerman.id.au

powerpc/pseries: Always inline functions called from cpuidle

Code in the idle path is not allowed to be instrumented because RCU is
disabled, see commit 0e985e9d2286 ("cpuidle: Add comments about
noinstr/__cpuidle usage").

Force inlining of the inline functions called from cpuidle, to ensure
they are not emitted out-of-line and then available for tracing.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230406144535.3786008-4-mpe@ellerman.id.au

cpuidle: pseries: Mark ->enter() functions as __cpuidle

Code in the idle path is not allowed to be instrumented because RCU is
disabled, see commit 0e985e9d2286 ("cpuidle: Add comments about
noinstr/__cpuidle usage").

Mark the cpuidle ->enter() callbacks as __cpuidle and use the
raw_local_irq_*() routines to ensure that is the case.

Reported-by: Sachin Sant <sachinp@linux.ibm.com>
Link: https://lore.kernel.org/all/4C073F6A-C812-4C4A-BB7A-ECD10B75FB88@linux.ibm.com/
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Tested-by: Sachin Sant <sachinp@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230406144535.3786008-3-mpe@ellerman.id.au

powerpc/64: Don't call trace_hardirqs_on() in prep_irq_for_idle()

Since commit a01353cf1896 ("cpuidle: Fix ct_idle_*() usage"), the
cpuidle entry code calls trace_hardirqs_on() (actually
trace_hardirqs_on_prepare()) in ct_cpuidle_enter() before calling into
the cpuidle driver.

Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230406144535.3786008-2-mpe@ellerman.id.au

powerpc/64: Mark prep_irq_for_idle() __cpuidle

Code in the idle path is not allowed to be instrumented because RCU is
disabled, see commit 0e985e9d2286 ("cpuidle: Add comments about
noinstr/__cpuidle usage").

Mark prep_irq_for_idle() __cpuidle, which is equivalent to noinstr, to
enforce that.

Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230406144535.3786008-1-mpe@ellerman.id.au

powerpc/irq: Mark check_return_regs_valid() notrace

check_return_regs_valid() is called from the middle of the irq exit
handling, which is all notrace, so mark it notrace also.

Reported-by: Sachin Sant <sachinp@linux.ibm.com>
Link: https://lore.kernel.org/all/4C073F6A-C812-4C4A-BB7A-ECD10B75FB88@linux.ibm.com/
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230406122118.3760344-1-mpe@ellerman.id.au

powerpc/corenet: Add PPC_QEMU_E500 to corenet configs

Add PPC_QEMU_E500 to corenet_base.config, which is then used to generate
corenet64_smp_defconfig and corenet32_smp_defconfig.

That then allows both those configs to build kernels that boot in qemu
using the ppce500 machine type and respectively -cpu e5500 or -cpu
e500mc.

The code that is added by PPC_QEMU_E500 just defines another machine
with a probe function that recognises qemu, so there should be no change
when booting on actual hardware supported by CORENET_GENERIC.

The increase in vmlinux size is less than 1KB.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230411102838.512859-1-mpe@ellerman.id.au

powerpc: drop MPC8272-ADS and PowerQUICC II FADS shared code.

With the two platforms depending on this shared code, and no others,
we can remove the orphaned code and Kconfigs

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230224204959.17425-4-paul.gortmaker@windriver.com

powerpc: drop PowerQUICC II Family ADS platform support

Based on documentation revision dates, this MPC82xx pq2fads system
predates the MPC8272-ADS variant by about a year and only has 1/2
the amount of RAM (32MB) -- largely making it useless with a modern
v6.x kernel from today.

Similar to the MPC8272-ADS the pq2fads also supported other 82xx CPU
variants, had 8MB flash, and like the 8272 ADS platform, was on a fairly
large PCB in order to have space for breakout connectors for all features.

These 82xx platforms are two decades old, and originally made for a
small group of industry related people in order to assist in new OEM
board designs.  Given that, it makes sense to remove support today.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230224204959.17425-3-paul.gortmaker@windriver.com

powerpc: drop MPC8272_ADS platform support

The MPC8272-ADS also supported other 82xx CPU variants, had 64MB RAM,
8MB flash, and like the 85xx ADS platforms, was on a fairly large PCB
in order to have space for breakout connectors for all the features.

These 82xx platforms are two decades old, and originally made for a
small group of industry related people in order to assist in new OEM
board designs.  Given that, it makes sense to remove support today.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230224204959.17425-2-paul.gortmaker@windriver.com

powerpc: drop HPCD/MPC8610 evaluation platform support

This evaluation platform was essentially a single core 8641 with
integrated graphics/display support - in an effort to reduce chip count
on kiosk and similar applications.

Compared to other evaluation platforms considered for removal in other
recent commits, this platform was relatively rare.  Unlike all the other
10+ platforms, I couldn't find any documentation on it - just a link to
downloading the 2007 era BSP in "LTIB" format as was done back then.

With all that in mind, it seems prudent to remove it here in 2023.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
[mpe: Drop stale reference to MPC8610_HPCD in 86xx/Kconfig]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230225201318.3682-4-paul.gortmaker@windriver.com

powerpc: drop HPC-NET/MPC8641D evaluation platform support

There is no denying that this was an interesting platform in its day.
Access to a SMP powerpc platform became a bit more obtainable for folks
in the BSP industry in the 2007 era, thanks to this platform.

Add to that the move to the black Antec case vs. the generic white 2005
era case of the MPC8548CDS or the retro 1950s 1/2 height horizontal case
of the HPC II, and it was pretty interesting to people like myself then.

However, like all the other evaluation platforms, the overall system
was complex out of necessity, as it tried to showcase all possible
features and use-cases.  That included an AMP option, where you could run
two bootloaders and two kernels over two serial consoles.  Peripheral
sharing got a bit more tricky when you got to the hard disk and similar.

In any case we still have the same circumstance.  A relatively rare and
expensive evaluation platform that is now 15+ years old and not out there
in large numbers in the general public.  Removal in 2023 just makes sense.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230225201318.3682-3-paul.gortmaker@windriver.com

powerpc: drop HPC II (MPC7448) evaluation platform support.

This was an interesting platform - it was the 1st instance of a
respin of earlier 130nm 74xx CPUs on 90nm and systems using MPC7448
were positioned as a rack server platform solution.

Given that, the evaluation platform (at least the one I had) was shipped
in a horizontal 1/2 height Antec desktop case with retro styling and
colours, despite the fact the docs explicitly stated that the HPC II is
not a desktop machine (noting it had no gfx or legacy PC I/O support).

Historic trivia aside, this was the 1st introduction of the e600
procfam as an evolution from the earlier G4.

However even with the claim to being "1st e600" it seems the 2005+
era was turning its attention to multicore support and from my memory
this poor guy was quickly overshadowed by the dual core MPC8641D.

All that aside, we are once again looking at 15+ year old evaluation
platforms that were not widely distributed, so 2023 removal makes sense.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230225201318.3682-2-paul.gortmaker@windriver.com

powerpc: drop MPC832x_MDS platform support

This final variant in the e300 family of Modular Development System
(MDS) in this series was actually aimed at feature reduction - things
like floating point and ethernet were removed in order to make for a
lower power and lower cost system.

Like all the MDS systems, it was meant as a vehicle to get the CPU out
early to hardware OEMs so software and board development could take place
in parallel.

These were made in limited numbers and availability preference was given
to partners who were planning to make their own boards.

Given that the whole reason for existence was to assist in enabling new
board designs [not happening for 10+ years], and that they weren't
generally available, and that the hardware wasn't really hobbyist friendly
even for retro computing, it makes sense to retire the support for this
particular platform.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Li Yang <leoyang.li@nxp.com>
[mpe: Drop stale reference to MPC832x_MDS in arch/powerpc/boot/Makefile]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230220115913.25811-5-paul.gortmaker@windriver.com

powerpc: drop MPC837x_MDS platform support

This next evolutionary step in the e300 family of Modular Development
System (MDS) still has, at its core component, a full length card with a
PCI edge.  No case.  Serial and network connectors were on card, so it
could optionally be fitted with plastic stand-offs and run stand-alone
off a power brick.

This is very similar to the MPC834x_MDS and MPC836x_MDS removed in the
prior commits, but with this board variant as yet another evolutionary
step.  SATA and PCI-e were now available.  But overall the form factor
and design goals were unchanged.

Like all the MDS systems, it was meant as a vehicle to get the CPU out
early to hardware OEMs so software and board development could take place
in parallel.

These were made in limited numbers and availability preference was given
to partners who were planning to make their own boards.

Given that the whole reason for existence was to assist in enabling new
board designs [not happening for 10+ years], and that they weren't
generally available, and that the hardware wasn't really hobbyist friendly
even for retro computing, it makes sense to retire the support for this
particular platform.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Li Yang <leoyang.li@nxp.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230220115913.25811-4-paul.gortmaker@windriver.com

powerpc: drop MPC836x_MDS platform support

This 2006 era Modular Development System (MDS) has, at its core component,
a full length card with a PCI edge.  No case.  Serial and network
connectors were on card, so it could optionally be fitted with plastic
stand-offs and run stand-alone off a power brick.

This is very similar to the MPC834x_MDS removed in the prior commit, but
with this board variant as an evolutionary step.  DDR2 was now an option,
and the card edge was revised down to PCI-32 as PCI-64 never got traction.
But overall the form factor and design goals were unchanged.

Like all the MDS systems, it was meant as a vehicle to get the CPU out
early to hardware OEMs so software and board development could take place
in parallel.

To that end, the BGA CPU was held in place with a mechanical spring loaded
pressure assembly (vs. solder) so that early rev silicon could be replaced
in the field.  Not for COTS deployment!

These were made in limited numbers and availability preference was given
to partners who were planning to make their own boards.

Given that the whole reason for existence was to assist in enabling new
board designs [not happening for 10+ years], and that they weren't
generally available, and that the hardware wasn't really hobbyist friendly
even for retro computing, it makes sense to retire the support for this
particular platform.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Li Yang <leoyang.li@nxp.com>
[mpe: Drop stale reference to MPC836x_MDS in arch/powerpc/boot/Makefile]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230220115913.25811-3-paul.gortmaker@windriver.com

powerpc: drop MPC834x_MDS platform support

This 2006 era Modular Development System (MDS) has, at its core
component, a full length card with a PCI-64 edge.  No case.  Serial
and network connectors were on card, so it could optionally be fitted
with plastic stand-offs and run stand-alone off a power brick.

Like all the MDS systems, it was meant as a vehicle to get the CPU
out early to hardware OEMs so software and board development could
take place in parallel.

To that end, the BGA CPU was held in place with a mechanical spring
loaded pressure assembly (vs. solder) so that early rev silicon could
be replaced in the field.  Not for COTS deployment!

These were made in limited numbers and availability preference was
given to partners who were planning to make their own boards, like
our WR SBC8349 [since retired in v4.18 (2017, commit 3bc6cf5a86e5)]

Given that the whole reason for existence was to assist in enabling
new board designs [not happening for 10+ years], and that they weren't
generally available, and that the hardware wasn't really hobbyist
friendly even for retro computing, it makes sense to retire the
support for this platform.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Li Yang <leoyang.li@nxp.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230220115913.25811-2-paul.gortmaker@windriver.com

powerpc/pseries: Add FW_FEATURE_PLPKS feature flag

Add a firmware feature flag, FW_FEATURE_PLPKS, to indicate availability of
Platform KeyStore related hcalls.

Check this flag in plpks_is_available() and pseries_plpks_init() before
trying to make an hcall.

Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230224041012.772648-1-ajd@linux.ibm.com

selftests/powerpc/dscr: Restore timeout to DSCR selftests

Reducing the time taken by dscr_sysfs_test.c allows restoring the
default timeout, which was removed in
commit 850507f30c38 ("selftests/powerpc: Turn off timeout setting for
benchmarks, dscr, signal, tm") because that test took too long.

Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230406043320.125138-8-bgray@linux.ibm.com

selftests/powerpc/dscr: Speed up DSCR sysfs tests

This test case is extremely slow, taking around a minute compared to
most of the other DSCR tests taking a second at most. Perf shows most
time is spent by the kernel switching to each CPU it reads in
/sys/devices/system/cpu. This switching is an unavoidable consequnce
of reading all the .../cpuN/dscr values.

Remove the outer iteration loop from this test case, reducing the reads
from 1600 to 16. This still updates the DSCR 16 times and verifies on
every CPU each time, so I do not expect the lower coverage to be
meaningful. The speedup is significant: back down to ~1 second like the
other tests.

Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230406043320.125138-7-bgray@linux.ibm.com

selftests/powerpc/dscr: Improve DSCR explicit random test case

The tests currently have a single writer thread updating the system
DSCR with a 1/1000 chance looped only 100 times. So only around one in
10 runs actually do anything.

* Add multiple threads to the dscr_explicit_random_test case.
* Use a barrier to make all the threads start work as simultaneously as
  possible.
* Use a rwlock and make all threads have a reasonable chance to write to
  the DSCR on each iteration.
  PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP is used to prevent
  writers from starving while all the other threads keep reading.
  Logging the reads/writes shows a decent mix across the whole test.
* Allow all threads a chance to write.
* Make the chance of writing more likely.

Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230406043320.125138-6-bgray@linux.ibm.com

selftests/powerpc/dscr: Add lockstep test cases to DSCR explicit tests

Add new cases to the relevant tests that use explicitly synchronized
threads to test the behaviour across context switches with less
randomness. By locking the participants to the same CPU we guarantee a
context switch occurs each time they make progress, which is a likely
failure point if the kernel is not tracking the thread local DSCR
correctly.

The random case is left in to keep exercising potential edge cases.

Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230406043320.125138-5-bgray@linux.ibm.com

selftests/powerpc: Allow bind_to_cpu() to automatically pick CPU

All current users of bind_to_cpu() don't care _which_ CPU they get, just
that they are bound to a single free one. So alter the interface to

1. Accept a BIND_CPU_ANY value that tells it to automatically
   pick a CPU
2. Return the picked CPU

And convert all these users to bind_to_cpu(BIND_CPU_ANY).

Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230406043320.125138-4-bgray@linux.ibm.com

selftests/powerpc: Move bind_to_cpu() to utils.h

This function will be useful in the DSCR test patches later in this
series, so promote it to be shared by all powerpc selftests.

Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230406043320.125138-3-bgray@linux.ibm.com

selftests/powerpc/dscr: Correct typos

Correct a couple of typos while working on other improvements to the
DSCR tests.

Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230406043320.125138-2-bgray@linux.ibm.com

powerpc: Remove duplicate SPRN_HSRR definitions

There are two copies of these defines. Keep the older ones as they have
associated bit definitions.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230405045316.95003-1-joel@jms.id.au

powerpc/64: modules support building with PCREL addresing

Build modules using PCREL addressing when CONFIG_PPC_KERNEL_PCREL=y.

- The module loader must handle several new relocation types:

  * R_PPC64_REL24_NOTOC is a function call handled like R_PPC_REL24, but
    does not restore r2 upon return. The external function call stub is
    changed to use pcrel addressing to load the function pointer rather
    than based on the module TOC.

  * R_PPC64_GOT_PCREL34 is a reference to external data. A GOT table
    must be built by hand, because the linker adds this during the final
    link (which is not done for kernel modules). The GOT table is built
    similarly to the way the external function call stub table is. This
    section is called .mygot because .got has a special meaning for the
    linker and can become upset.

  * R_PPC64_PCREL34 is used for local data addressing, but there is a
    special case where the percpu section is moved at load-time to the
    percpu area which is out of range of this relocation. This requires
    the PCREL34 relocations are converted to use GOT_PCREL34 addressing.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
[mpe: Some coding style & formatting fixups]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408021752.862660-7-npiggin@gmail.com

powerpc/64: vmlinux support building with PCREL addresing

PC-Relative or PCREL addressing is an extension to the ELF ABI which
uses Power ISA v3.1 PC-relative instructions to calculate addresses,
rather than the traditional TOC scheme.

Add an option to build vmlinux using pcrel addressing. Modules continue
to use TOC addressing.

- TOC address helpers and r2 are poisoned with -1 when running vmlinux.
  r2 could be used for something useful once things are ironed out.

- Assembly must call C functions with @notoc annotation, or the linker
  complains aobut a missing nop after the call. This is done with the
  CFUNC macro introduced earlier.

- Boot: with the exception of prom_init, the execution branches to the
  kernel virtual address early in boot, before any addresses are
  generated, which ensures 34-bit pcrel addressing does not miss the
  high PAGE_OFFSET bits. TOC relative addressing has a similar
  requirement. prom_init does not go to the virtual address and its
  addresses should not carry over to the post-prom kernel.

- Ftrace trampolines are converted from TOC addressing to pcrel
  addressing, including module ftrace trampolines that currently use the
  kernel TOC to find ftrace target functions.

- BPF function prologue and function calling generation are converted
  from TOC to pcrel.

- copypage_64.S has an interesting problem, prefixed instructions have
  alignment restrictions so the linker can add padding, which makes the
  assembler treat the difference between two local labels as
  non-constant even if alignment is arranged so padding is not required.
  This may need toolchain help to solve nicely, for now move the prefix
  instruction out of the alternate patch section to work around it.

This reduces kernel text size by about 6%.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408021752.862660-6-npiggin@gmail.com

powerpc: add CFUNC assembly label annotation

This macro is to be used in assembly where C functions are called.
pcrel addressing mode requires branches to functions with a
localentry value of 1 to have either a trailing nop or @notoc.
This macro permits the latter without changing callers.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
[mpe: Add dummy definitions to fix selftests build]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408021752.862660-5-npiggin@gmail.com

powerpc/64: Add support to build with prefixed instructions

Add an option to build kernel and module with prefixed instructions if
the CPU and toolchain support it.

This is not related to kernel support for userspace execution of
prefixed instructions.

Building with prefixed instructions breaks some extended inline asm
memory addressing, for example it will provide immediates that exceed
the range of simple load/store displacement. Whether this is a
toolchain or a kernel asm problem remains to be seen. For now, these
are replaced with simpler and less efficient direct register addressing
when compiling with prefixed.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408021752.862660-4-npiggin@gmail.com

powerpc/64s: Run at the kernel virtual address earlier in boot

This mostly consolidates the Book3E and Book3S behaviour in boot WRT
executing from the physical or virtual address.

Book3E sets up kernel virtual linear map in start_initialization_book3e
and runs from the virtual linear alias after that. This change makes
Book3S begin to execute from the virtual alias at the same point. Book3S
can not use its MMU for that at this point, but when the MMU is disabled,
the virtual linear address correctly aliases to physical memory because
the top bits of the address are ignored with MMU disabled.

Secondaries execute from the virtual address similarly early.

This reduces the differences between subarchs, but the main motivation
was to enable the PC-relative addressing ABI for Book3S, where pointer
calculations must execute from the virtual address or the top bits of
the pointer will be lost. This is similar to the requirement the TOC
relative addressing already has that the TOC pointer use its virtual
address.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408021752.862660-3-npiggin@gmail.com

powerpc/64: Move initial base and TOC pointer calculation

A later change moves the non-prom case to run at the virtual address
earlier, which calls for virtual TOC and kernel base. Split these two
calculations for prom and non-prom to make that change simpler.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
[mpe: Retain relative_toc call for start_initialization_book3e]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408021752.862660-2-npiggin@gmail.com

powerpc: dts: turris1x.dts: Remove "fsl,P2020RDB-PC" compatible string

"fsl,P2020RDB-PC" compatible string was present in Turris 1.x DTS file just
because Linux kernel required it for proper detection of P2020 processor
during boot.

This was quite a hack as CZ.NIC Turris 1.x is not compatible with
Freescale P2020-RDB-PC board.

Now when kernel has generic unified support for boards with P2020
processors, there is no need to have this "hack" in turris1x.dts file.

So remove incorrect "fsl,P2020RDB-PC" compatible string from turris1x.dts.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408140122.25293-14-pali@kernel.org

powerpc/85xx: p2020: Enable boards by new config option CONFIG_PPC_P2020

Generic unified P2020 machine description which supports all P2020-based
boards is now in separate file p2020.c. So create a separate config option
CONFIG_PPC_P2020 for it.

Previously machine descriptions for P2020 boards were enabled by
CONFIG_MPC85xx_DS or CONFIG_MPC85xx_RDB option. So set CONFIG_PPC_P2020 to
be enabled by default when one of those option is enabled.

This allows to compile support for P2020 boards without need to have
enabled support for older mpc85xx boards. And to compile kernel for old
mpc85xx boards without having enabled support for new P2020 boards.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408140122.25293-13-pali@kernel.org

powerpc/85xx: p2020: Define just one machine description

Combine machine descriptions and code of all P2020 boards into just one
generic unified P2020 machine description. This allows kernel to boot on
any P2020-based board with P2020 DTS file without need to patch kernel and
define a new machine description in 85xx powerpc platform directory.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408140122.25293-12-pali@kernel.org

powerpc/85xx: p2020: Unify .setup_arch and .init_IRQ callbacks

Make just one .setup_arch and one .init_IRQ callback implementation for all
P2020 board code. This deduplicate repeated and same code.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408140122.25293-11-pali@kernel.org

powerpc/85xx: mpc85xx_ds: Move i8259 code into own file

In order to share mpc85xx i8259 code between DS and P2020.
Prefix i8259 debug and error messages by i8259 word.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
[mpe: Fix some coding style warnings in the moved code]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408140122.25293-10-pali@kernel.org

powerpc/85xx: p2020: Move all P2020 RDB machine descriptions to p2020.c

This moves P2020 RDB machine descriptions into new p2020.c source file.
This is preparation for code de-duplication and providing one unified
machine description for all P2020 boards.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408140122.25293-9-pali@kernel.org

powerpc/85xx: p2020: Move all P2020 DS machine descriptions to p2020.c

This moves P2020 DS machine descriptions into new p2020.c source file.
This is preparation for code de-duplication and providing one unified
machine description for all P2020 boards.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408140122.25293-8-pali@kernel.org

powerpc/85xx: Remove #ifdef CONFIG_QUICC_ENGINE in mpc85xx_rdb

mpc85xx_qe_par_io_init() is a stub when CONFIG_QUICC_ENGINE is not set.

CONFIG_UCC_GETH and CONFIG_SERIAL_QE depend on CONFIG_QUICC_ENGINE.

Remove #ifdef CONFIG_QUICC_ENGINE

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408140122.25293-7-pali@kernel.org

powerpc/85xx: Remove #ifdefs CONFIG_PPC_I8259 in mpc85xx_ds

All necessary items are declared all the time, no need to use
a #ifdef CONFIG_PPC_I8259.

Refactor CONFIG_PPC_I8259 actions into a dedicated init function.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408140122.25293-6-pali@kernel.org

powerpc/85xx: mpc85xx_{ds/rdb} replace prink by pr_xxx macro

Use pr_debug() instead of printk(KERN_DEBUG
Use pr_err() instead of printk(KERN_ERR
Use pr_info() instead of printk(KERN_INFO or printk("

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408140122.25293-5-pali@kernel.org

powerpc/85xx: mpc85xx_{ds/rdb} replace BUG_ON() by WARN_ON()

No need to BUG() in case mpic_alloc() fails. Use WARN_ON().

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408140122.25293-4-pali@kernel.org

powerpc/85xx: mpc85xx_{ds/rdb} compact the call to mpic_alloc()

Reduce number of lines in the call to mpic_alloc().

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408140122.25293-3-pali@kernel.org

powerpc/85xx: Remove DBG() macro

DBG() macro is defined at three places while used only
one time at one place.

Replace its only use by a pr_debug() and remove the macro.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230408140122.25293-2-pali@kernel.org

powerpc/fsl_uli1575: Mark uli_exclude_device() as static

Function uli_exclude_device() is not used outside of the fsl_uli1575.c
source file anymore. So mark it as static and remove public prototype.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230409000812.18904-9-pali@kernel.org

powerpc/86xx: mpc86xx_hpcn: Call uli_init() instead of explicit ppc_md assignment

After calling fsl_pci_assign_primary(), it is possible to use uli_init() to
conditionally initialize ppc_md.pci_exclude_device callback based on the
uli1575 detection.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230409000812.18904-8-pali@kernel.org

powerpc/fsl_uli1575: Allow to disable FSL_ULI1575 support

ULI1575 PCIe south bridge exists only on some Freescale boards. Allow to
disable CONFIG_FSL_ULI1575 symbol when it is not explicitly selected and
only implied. This is achieved by marking symbol as visible by providing
short description. Also adds dependency for this symbol to prevent enabling
it on platforms on which driver does not compile.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230409000812.18904-7-pali@kernel.org

powerpc/85xx: mpc85xx_rdb: Do not automatically select FSL_ULI1575

Boards provided by CONFIG_MPC85xx_RDB option do not initialize
fsl_uli1575.c driver. So remove explicit select dependency on it.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230409000812.18904-6-pali@kernel.org

powerpc/85xx: mpc85xx_ds: Move uli_init() code into its own driver file

Move uli_init() function into existing driver fsl_uli1575.c file in order
to share its code between more platforms and board files.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230409000812.18904-5-pali@kernel.org

powerpc/fsl_uli1575: Simplify uli_exclude_device() usage

Function uli_exclude_device() is called only from mpc86xx_exclude_device()
and mpc85xx_exclude_device() functions. Both those functions are same, so
merge its logic directly into the uli_exclude_device() function.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230409000812.18904-4-pali@kernel.org

powerpc/85xx: mpc85xx_ds: Simplify mpc85xx_exclude_device() function

Function mpc85xx_exclude_device() is installed and used only when
pci_with_uli is fsl_pci_primary. So replace check for pci_with_uli by
fsl_pci_primary in mpc85xx_exclude_device() and move pci_with_uli variable
declaration into function mpc85xx_ds_uli_init() where it is used.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230409000812.18904-3-pali@kernel.org

powerpc/fsl_uli1575: Misc cleanup

Use a single line for uli_exclude_device().

Add uli_exclude_device() prototype in ppc-pci.h and guard it.

Remove that prototype from mpc85xx_ds.c and mpc86xx_hpcn.c files.

Make uli_pirq_to_irq[] static as it is used only in that file.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230409000812.18904-2-pali@kernel.org

powerpc/boot: Fix boot wrapper code generation with CONFIG_POWER10_CPU

-mcpu=power10 will generate prefixed and pcrel code by default, which
we do not support. The general kernel disables these with cflags, but
those were missed for the boot wrapper.

Fixes: 4b2a9315f20d ("powerpc/64s: POWER10 CPU Kconfig build option")
Cc: stable@vger.kernel.org # v6.1+
Reported-by: Danny Tsen <dtsen@linux.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230407040909.230998-1-npiggin@gmail.com

powerpc/boot: Fix crt0.S current address branch form

Use the preferred form of branch-and-link for finding the current
address so objtool doesn't think it is an unannotated intra-function
call.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230407040924.231023-1-npiggin@gmail.com

powerpc/32: Include thread_info.h in head_booke.h

When building with W=1 after commit 80b6093b55e3 ("kbuild: add -Wundef
to KBUILD_CPPFLAGS for W=1 builds"), the following warning occurs.

  In file included from arch/powerpc/kvm/bookehv_interrupts.S:26:
  arch/powerpc/kvm/../kernel/head_booke.h:20:6: warning: "THREAD_SHIFT" is not defined, evaluates to 0 [-Wundef]
     20 | #if (THREAD_SHIFT < 15)
        |      ^~~~~~~~~~~~

THREAD_SHIFT is defined in thread_info.h but it is not directly included
in head_booke.h, so it is possible for THREAD_SHIFT to be undefined. Add
the include to ensure that THREAD_SHIFT is always defined.

Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/202304050954.yskLdczH-lkp@intel.com/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230406-wundef-thread_shift_booke-v1-1-8deffa4d84f9@kernel.org

powerpc: copy_thread don't set PPR in user interrupt frame regs

syscalls do not set the PPR field in their interrupt frame and
return from syscall always sets the default PPR for userspace,
so setting the value in the ret_from_fork frame is not necessary
and mildly inconsistent. Remove it.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230325122904.2375060-9-npiggin@gmail.com

powerpc: copy_thread don't set _TIF_RESTOREALL

In the kernel user thread path, don't set _TIF_RESTOREALL because
the thread is required to call kernel_execve() before it returns,
which will set _TIF_RESTOREALL if necessary via start_thread().

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230325122904.2375060-8-npiggin@gmail.com

powerpc: differentiate kthread from user kernel thread start

Kernel created user threads start similarly to kernel threads in that
they call a kernel function after first returning from _switch, so
they share ret_from_kernel_thread for this. Kernel threads never return
from that function though, whereas user threads often do (although some
don't, e.g., IO threads).

Split these startup functions in two, and catch kernel threads that
improperly return from their function. This is intended to make the
complicated code a little bit easier to understand.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230325122904.2375060-7-npiggin@gmail.com

powerpc: copy_thread differentiate kthreads and user mode threads

When copy_thread is given a kernel function to run in arg->fn, this
does not necessarily mean it is a kernel thread. User threads can be
created this way (e.g., kernel_init, see also x86's copy_thread()).
These threads run a kernel function which may call kernel_execve()
and return, which returns like a userspace exec(2) syscall.

Kernel threads are to  be differentiated with PF_KTHREAD, will always
have arg->fn set, and should never return from that function, instead
calling kthread_exit() to exit.

Create separate paths for the kthread and user kernel thread creation
logic. The kthread path will never exit and does not require a user
interrupt frame, so it gets a minimal stack frame.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230325122904.2375060-6-npiggin@gmail.com

powerpc/64: ret_from_fork avoid restoring regs twice

If the system call return path always restores NVGPRs then there is no
need for ret_from_fork to do it. The HANDLER_RESTORE_NVGPRS does the
right thing for this.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230325122904.2375060-5-npiggin@gmail.com

powerpc: use switch frame for ret_from_kernel_thread parameters

The kernel thread path in copy_thread creates a user interrupt frame on
stack and stores the function and arg parameters there, and
ret_from_kernel_thread loads them. This is a slightly confusing way to
overload that frame. Non-volatile registers are loaded from the switch
frame, so the parameters can be stored there. The user interrupt frame
is now only used by user threads when they return to user.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230325122904.2375060-4-npiggin@gmail.com

powerpc: copy_thread make ret_from_fork register setup consistent

The ret_from_fork code for 64e and 32-bit set r3 for
syscall_exit_prepare the same way that 64s does, so there should
be no need to special-case them in copy_thread.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230325122904.2375060-3-npiggin@gmail.com

powerpc: copy_thread remove unused pkey code

The pkey registers (AMR, IAMR) do not get loaded from the switch frame
so it is pointless to save anything there. Remove the dead code.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230325122904.2375060-2-npiggin@gmail.com

powerpc/64: Always build with 128-bit long double

The amdgpu driver builds some of its code with hard-float enabled,
whereas the rest of the kernel is built with soft-float.

When building with 64-bit long double, if soft-float and hard-float
objects are linked together, the build fails due to incompatible ABI
tags.

In the past there have been build errors in the amdgpu driver caused by
this, some of those were due to bad intermingling of soft & hard-float
code, but those issues have now all been fixed since commit 58ddbecb14c7
("drm/amd/display: move remaining FPU code to dml folder").

However it's still possible for soft & hard-float objects to end up
linked together, if the amdgpu driver is built-in to the kernel along
with the test_emulate_step.c code, which uses soft-float. That happens
in an allyesconfig build.

Currently those build errors are avoided because the amdgpu driver is
gated on 128-bit long double being enabled. But that's not a detail the
amdgpu driver should need to be aware of, and if another driver starts
using hard-float the same problem would occur.

All versions of the 64-bit ABI specify that long-double is 128-bits.
However some compilers, notably the kernel.org ones, are built to use
64-bit long double by default.

Apart from this issue of soft vs hard-float, the kernel doesn't care
what size long double is. In particular the kernel using 128-bit long
double doesn't impact userspace's ability to use 64-bit long double, as
musl does.

So always build the 64-bit kernel with 128-bit long double. That should
avoid any build errors due to the incompatible ABI tags. Excluding the
code that uses soft/hard-float, the vmlinux is identical with/without
the flag.

It does mean any code which is incorrectly intermingling soft &
hard-float code will build without error, so those bugs will need to be
caught by testing rather than at build time.

For more background see:
  - commit d11219ad53dc ("amdgpu: disable powerpc support for the newer display engine")
  - commit c653c591789b ("drm/amdgpu: Re-enable DCN for 64-bit powerpc")
  - https://lore.kernel.org/r/dab9cbd8-2626-4b99-8098-31fe76397d2d@app.fastmail.com

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Link: https://msgid.link/20230404102847.3303623-1-mpe@ellerman.id.au

powerpc/atomics: Remove unused function

Remove arch_atomic_try_cmpxchg_lock function as it is no longer used
since commit 9f61521c7a28 ("powerpc/qspinlock: powerpc qspinlock
implementation")

Signed-off-by: Nysal Jan K.A <nysal@linux.ibm.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230224103940.1328725-1-nysal@linux.ibm.com

powerpc: Implement arch_within_stack_frames

Walks the stack when copy_{to,from}_user address is in the stack to
ensure that the object being copied is entirely a single stack frame and
does not contain stack metadata.

Substantially similar to the x86 implementation. The back chain is used
to traverse the stack and identify stack frame boundaries.

Signed-off-by: Nicholas Miehlbradt <nicholas@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230228054355.300628-1-nicholas@linux.ibm.com

powerpc: Use of_address_to_resource()

Replace open coded reading of "reg" or of_get_address()/
of_translate_address() calls with a single call to
of_address_to_resource().

Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230329220337.141295-1-robh@kernel.org

powerpc/usbgecko: Use of_iomap()

Replace of_get_property()+of_translate_address()+ioremap() with a call
to of_iomap() which does all those steps.

Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230327223109.820381-1-robh@kernel.org

powerpc/fsl_rio: Use of_iomap()

Replace of_address_to_resource()+ioremap() with a call to of_iomap()
which does both of those steps.

Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230327223103.820229-1-robh@kernel.org

powerpc/xics: Use of_address_count()

icp_native_init_one_node() only needs the number of entries in "reg".
Replace the open coded "reg" parsing with of_address_count() to get the
number of "reg" entries.

Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230327223056.820086-1-robh@kernel.org

powerpc/isa-bridge: Remove open coded "ranges" parsing

"ranges" is a standard property with common parsing functions. Users
shouldn't be implementing their own parsing of it. Reimplement the
ISA brige "ranges" parsing using the common ranges iterator functions.

The common routines are flexible enough to work on PCI and non-PCI to
ISA bridges, so refactor pci_process_ISA_OF_ranges() and
isa_bridge_init_non_pci() into a single implementation.

Signed-off-by: Rob Herring <robh@kernel.org>
[mpe: Unsplit some strings and use pr_xxx()]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230327223045.819852-1-robh@kernel.org

Merge branch 'topic/ppc-kvm' into next

Merge our KVM topic branch to bring some KVM commits into next for wider
testing.

KVM: PPC: Enable prefixed instructions for HV KVM and disable for PR KVM

Now that we can read prefixed instructions from a HV KVM guest and
emulate prefixed load/store instructions to emulated MMIO locations,
we can add HFSCR_PREFIXED into the set of bits that are set in the
HFSCR for a HV KVM guest on POWER10, allowing the guest to use
prefixed instructions.

PR KVM has not yet been extended to handle prefixed instructions in
all situations where we might need to emulate them, so prevent the
guest from enabling prefixed instructions in the FSCR for now.

Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Tested-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Tested-by: Sachin Sant <sachinp@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/ZAgs25dCmLrVkBdU@cleo

KVM: PPC: Fetch prefixed instructions from the guest

In order to handle emulation of prefixed instructions in the guest,
this first makes vcpu->arch.last_inst be an unsigned long, i.e. 64
bits on 64-bit platforms.  For prefixed instructions, the upper 32
bits are used for the prefix and the lower 32 bits for the suffix, and
both halves are byte-swapped if the guest endianness differs from the
host.

Next, vcpu->arch.emul_inst is now 64 bits wide, to match the HEIR
register on POWER10.  Like HEIR, for a prefixed instruction it is
defined to have the prefix is in the top 32 bits and the suffix in the
bottom 32 bits, with both halves in the correct byte order.

kvmppc_get_last_inst is extended on 64-bit machines to put the prefix
and suffix in the right places in the ppc_inst_t being returned.

kvmppc_load_last_inst now returns the instruction in an unsigned long
in the same format as vcpu->arch.last_inst.  It makes the decision
about whether to fetch a suffix based on the SRR1_PREFIXED bit in the
MSR image stored in the vcpu struct, which generally comes from SRR1
or HSRR1 on an interrupt.  This bit is defined in Power ISA v3.1B to
be set if the interrupt occurred due to a prefixed instruction and
cleared otherwise for all interrupts except for instruction storage
interrupt, which does not come to the hypervisor.  It is set to zero
for asynchronous interrupts such as external interrupts.  In previous
ISA versions it was always set to 0 for all interrupts except
instruction storage interrupt.

The code in book3s_hv_rmhandlers.S that loads the faulting instruction
on a HDSI is only used on POWER8 and therefore doesn't ever need to
load a suffix.

[npiggin@gmail.com - check that the is-prefixed bit in SRR1 matches the
type of instruction that was fetched.]

Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Tested-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/ZAgsq9h1CCzouQuV@cleo

KVM: PPC: Make kvmppc_get_last_inst() produce a ppc_inst_t

This changes kvmppc_get_last_inst() so that the instruction it fetches
is returned in a ppc_inst_t variable rather than a u32.  This will
allow us to return a 64-bit prefixed instruction on those 64-bit
machines that implement Power ISA v3.1 or later, such as POWER10.
On 32-bit platforms, ppc_inst_t is 32 bits wide, and is turned back
into a u32 by ppc_inst_val, which is an identity operation on those
platforms.

Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Tested-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/ZAgsiPlL9O7KnlZZ@cleo

KVM: PPC: Book3S HV: Set SRR1[PREFIX] bit on injected interrupts

Pass the hypervisor (H)SRR1[PREFIX] indication through to synchronous
interrupts injected into the guest.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230330103224.3589928-3-npiggin@gmail.com

KVM: PPC: Permit SRR1 flags in more injected interrupt types

The prefix architecture in ISA v3.1 introduces a prefixed bit in SRR1
for many types of synchronous interrupts which is set when the interrupt
is caused by a prefixed instruction.

This requires KVM to be able to set this bit when injecting interrupts
into a guest. Plumb through the SRR1 "flags" argument to the core_queue
APIs where it's missing for this. For now they are set to 0, which is
no change.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
[mpe: Fixup kvmppc_core_queue_alignment() in booke.c]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230330103224.3589928-2-npiggin@gmail.com

KVM: PPC: BookE: Fix W=1 warnings

Fix various W=1 warnings in booke.c:

  arch/powerpc/kvm/booke.c:1008:5: error: no previous prototype for ‘kvmppc_handle_exit’ [-Werror=missing-prototypes]
   1008 | int kvmppc_handle_exit(struct kvm_vcpu *vcpu, unsigned int exit_nr)
        |     ^~~~~~~~~~~~~~~~~~
  arch/powerpc/kvm/booke.c:1009: warning: Function parameter or member 'vcpu' not described in 'kvmppc_handle_exit'
  arch/powerpc/kvm/booke.c:1009: warning: Function parameter or member 'exit_nr' not described in 'kvmppc_handle_exit'

Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/202304020827.3LEZ86WB-lkp@intel.com/
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230403045314.3095410-1-mpe@ellerman.id.au

macintosh: Use of_property_present() for testing DT property presence

It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property/of_find_property functions for reading properties. As
part of this, convert of_get_property/of_find_property calls to the
recently added of_property_present() helper when we just want to test
for presence of a property and nothing more.

Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230310144735.1546817-1-robh@kernel.org

powerpc: Use of_property_read_bool() for boolean properties

It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property/of_find_property functions for reading properties.
Convert reading boolean properties to of_property_read_bool().

Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230310144659.1541127-1-robh@kernel.org

powerpc: Use of_property_present() for testing DT property presence

It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property/of_find_property functions for reading properties. As
part of this, convert of_get_property/of_find_property calls to the
recently added of_property_present() helper when we just want to test
for presence of a property and nothing more.

Signed-off-by: Rob Herring <robh@kernel.org>
[mpe: Drop change in ppc4xx_probe_pci_bridge(), formatting]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230310144657.1541039-1-robh@kernel.org

powerpc/rtas: lockdep annotations

Add lockdep annotations for the following properties that must hold:

* Any error log retrieval must be atomically coupled with the prior
  RTAS call, without a window for another RTAS call to occur before the
  error log can be retrieved.

* All users of the core rtas_args parameter block must hold rtas_lock.

Move the definitions of rtas_lock and rtas_args up in the file so that
__do_enter_rtas_trace() can refer to them.

Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230220-rtas-queue-for-6-4-v1-6-010e4416f13f@linux.ibm.com

powerpc/rtas: fix miswording in rtas_function kerneldoc

The 'filter' member is a pointer, not a bool; fix the wording
accordingly.

Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230220-rtas-queue-for-6-4-v1-4-010e4416f13f@linux.ibm.com

powerpc/rtas: rtas_call_unlocked() kerneldoc

Add documentation for rtas_call_unlocked(), including details on how
it differs from rtas_call().

Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230220-rtas-queue-for-6-4-v1-3-010e4416f13f@linux.ibm.com

powerpc/rtas: use memmove for potentially overlapping buffer copy

Using memcpy() isn't safe when buf is identical to rtas_err_buf, which
can happen during boot before slab is up. Full context which may not
be obvious from the diff:

if (altbuf) {
buf = altbuf;
} else {
buf = rtas_err_buf;
if (slab_is_available())
buf = kmalloc(RTAS_ERROR_LOG_MAX, GFP_ATOMIC);
}
if (buf)
memcpy(buf, rtas_err_buf, RTAS_ERROR_LOG_MAX);

This was found by inspection and I'm not aware of it causing problems
in practice. It appears to have been introduced by commit
033ef338b6e0 ("powerpc: Merge rtas.c into arch/powerpc/kernel"); the
old ppc64 version of this code did not have this problem.

Use memmove() instead.

Fixes: 033ef338b6e0 ("powerpc: Merge rtas.c into arch/powerpc/kernel")
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230220-rtas-queue-for-6-4-v1-2-010e4416f13f@linux.ibm.com