Even though ERET always causes a jump to another address, aarch64 CPUs
speculatively execute following instructions as if the ERET
instruction was not a jump instruction.
The speculative execution does not cross privilege-levels (to the jump
target as one would expect), but it continues on the kernel privilege
level as if the ERET instruction did not change the control flow -
thus execution anything that is accidentally linked after the ERET
instruction. Later, the results of this speculative execution are
always architecturally discarded, however they can leak data using
microarchitectural side channels. This speculative execution is very
reliable (seems to be unconditional) and it manages to complete even
relatively performance-heavy operations (e.g. multiple dependent
fetches from uncached memory).

This was fixed in Linux, FreeBSD, OpenBSD and Optee OS:
https://github.com/torvalds/linux/commit/679db70801da9fda91d26caf13bf5b5ccc74e8e8
https://github.com/freebsd/freebsd/commit/29fb48ace4186a41c409fde52bcf4216e9e50b61
https://github.com/openbsd/src/commit/3a08873ece1cb28ace89fd65e8f3c1375cc98de2
https://github.com/OP-TEE/optee_os/commit/abfd092aa19f9c0251e3d5551e2d68a9ebcfec8a

It is demonstrated in a SafeSide example:
https://github.com/google/safeside/blob/master/demos/eret_hvc_smc_wrapper.cc
https://github.com/google/safeside/blob/master/kernel_modules/kmod_eret_hvc_smc/eret_hvc_smc_module.c

Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Change-Id: Iead39b0b9fb4b8d8b5609daaa8be81497ba63a0f

Convert the R-Car Gen3 platform and both SCIF and Log drivers
to multi-console API.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Change-Id: I18556973937d150b60453f9150d54ee612571e35

Since the interrupts are handled in EL3, dump the EL3 error registers
in case an error happens.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>

Staticize the platform memory map tables as they are only used within
the platform_common.c file.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>

Rename the H3 label to avoid confusing clang, which generates an error
if the label is just H3. Rename it to RCARH3.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>

Enforce full include path for includes. Deprecate old paths.

The following folders inside include/lib have been left unchanged:

- include/lib/cpus/${ARCH}
- include/lib/el3_runtime/${ARCH}

The reason for this change is that having a global namespace for
includes isn't a good idea. It defeats one of the advantages of having
folders and it introduces problems that are sometimes subtle (because
you may not know the header you are actually including if there are two
of them).

For example, this patch had to be created because two headers were
called the same way: e0ea0928d5b7 ("Fix gpio includes of mt8173 platform
to avoid collision."). More recently, this patch has had similar
problems: 46f9b2c3a282 ("drivers: add tzc380 support").

This problem was introduced in commit 4ecca33988b9 ("Move include and
source files to logical locations"). At that time, there weren't too
many headers so it wasn't a real issue. However, time has shown that
this creates problems.

Platforms that want to preserve the way they include headers may add the
removed paths to PLAT_INCLUDES, but this is discouraged.

Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Signed-off-by: ldts <jorge.ramirez.ortiz@gmail.com>

Reference code:
==============

rar_gen3: IPL and Secure Monitor Rev1.0.22
https://github.com/renesas-rcar/arm-trusted-firmware [rcar_gen3]

Author: Takuya Sakata <takuya.sakata.wz@bp.renesas.com>
Date:   Thu Aug 30 21:26:41 2018 +0900
	Update IPL and Secure Monitor Rev1.0.22

General Information:
===================

This port has been tested on the Salvator-X Soc_id r8a7795 revision
ES1.1 (uses an SPD).

Build Tested:
-------------
ATFW_OPT="LSI=H3 RCAR_DRAM_SPLIT=1 RCAR_LOSSY_ENABLE=1"
MBEDTLS_DIR=$mbedtls

$ make clean bl2 bl31 rcar PLAT=rcar ${ATFW_OPT} SPD=opteed

Other dependencies:
------------------
* mbed_tls:
  git@github.com:ARMmbed/mbedtls.git [devel]

  Merge: 68dbc94 f34a4c1
  Author: Simon Butcher <simon.butcher@arm.com>
  Date:   Thu Aug 30 00:57:28 2018 +0100

* optee_os:
  https://github.com/BayLibre/optee_os

  Until it gets merged into OP-TEE, the port requires Renesas' Trusted
  Environment with a modification to support power management.

  Author: Jorge Ramirez-Ortiz <jramirez@baylibre.com>
  Date:   Thu Aug 30 16:49:49 2018 +0200
    plat-rcar: cpu-suspend: handle the power level
    Signed-off-by: Jorge Ramirez-Ortiz <jramirez@baylibre.com>

* u-boot:
  The port has beent tested using mainline uboot.

  Author: Fabio Estevam <festevam@gmail.com>
  Date:   Tue Sep 4 10:23:12 2018 -0300

*linux:
  The port has beent tested using mainline kernel.

  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Sun Sep 16 11:52:37 2018 -0700
      Linux 4.19-rc4

Overview
---------

BOOTROM starts the cpu at EL3; In this port BL2 will therefore be entered
at this exception level (the Renesas' ATF reference tree [1] resets into
EL1 before entering BL2 - see its bl2.ld.S)

BL2 initializes DDR (and i2c to talk to the PMIC on some platforms)
before determining the boot reason (cold or warm).

During suspend all CPUs are switched off and the DDR is put in
backup mode (some kind of self-refresh mode). This means that BL2 is
always entered in a cold boot scenario.

Once BL2 boots, it determines the boot reason, writes it to shared
memory (BOOT_KIND_BASE) together with the BL31 parameters
(PARAMS_BASE) and jumps to BL31.

To all effects, BL31 is as if it is being entered in reset mode since
it still needs to initialize the rest of the cores; this is the reason
behind using direct shared memory access to  BOOT_KIND_BASE and
PARAMS_BASE instead of using registers to get to those locations (see
el3_common_macros.S and bl31_entrypoint.S for the RESET_TO_BL31 use
case).

Depending on the boot reason BL31 initializes the rest of the cores:
in case of suspend, it uses a MBOX memory region to recover the
program counters.

[1] https://github.com/renesas-rcar/arm-trusted-firmware
Tests
-----

* cpuidle
  -------
   enable kernel's cpuidle arm_idle driver and boot

* system suspend
  --------------
  $ cat suspend.sh
    #!/bin/bash
    i2cset -f -y 7 0x30 0x20 0x0F
    read -p "Switch off SW23 and press return " foo
    echo mem > /sys/power/state

* cpu hotplug:
  ------------
  $ cat offline.sh
    #!/bin/bash
    nbr=$1
    echo 0 > /sys/devices/system/cpu/cpu$nbr/online
    printf "ONLINE:  " && cat /sys/devices/system/cpu/online
    printf "OFFLINE: " && cat /sys/devices/system/cpu/offline

  $ cat online.sh
    #!/bin/bash
    nbr=$1
    echo 1 > /sys/devices/system/cpu/cpu$nbr/online
    printf "ONLINE:  " && cat /sys/devices/system/cpu/online
    printf "OFFLINE: " && cat /sys/devices/system/cpu/offline

Signed-off-by: ldts <jramirez@baylibre.com>