In preparation to enable building scmi as a single module, let us move
the scmi bus {de-,}initialisation call into the driver.

The main reason for this is to keep it simple instead of maintaining
it as separate modules and dealing with all possible initcall races
and deferred probe handling. We can move it as separate modules if
needed in future.

Link: https://lore.kernel.org/r/20200907195046.56615-3-sudeep.holla@arm.comTested-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

We need to export both arm_smccc_1_1_get_conduit and arm_smccc_get_version
to allow several modules make use of them. Arm FFA, Arm SCMI and PTP
drivers are few drivers that are planning to use these functions.

Let us export them in preparation to add support for SCMI as module.

Link: https://lore.kernel.org/r/20200907195046.56615-2-sudeep.holla@arm.comSigned-off-by: NSudeep Holla <sudeep.holla@arm.com>

scmi_mailbox is obtained from cinfo->transport_info and the first
call to mailbox_chan_free frees the channel and sets cinfo->transport_info
to NULL. Care is taken to check for non NULL smbox->chan but smbox can
itself be NULL. Fix it by checking for it without which, kernel crashes
with below NULL pointer dereference and eventually kernel panic.

   Unable to handle kernel NULL pointer dereference at
   		virtual address 0000000000000038
   Modules linked in: scmi_module(-)
   Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno
   		Development Platform, BIOS EDK II Sep  2 2020
   pstate: 80000005 (Nzcv daif -PAN -UAO BTYPE=--)
   pc : mailbox_chan_free+0x2c/0x70 [scmi_module]
   lr : idr_for_each+0x6c/0xf8
   Call trace:
    mailbox_chan_free+0x2c/0x70 [scmi_module]
    idr_for_each+0x6c/0xf8
    scmi_remove+0xa8/0xf0 [scmi_module]
    platform_drv_remove+0x34/0x58
    device_release_driver_internal+0x118/0x1f0
    driver_detach+0x58/0xe8
    bus_remove_driver+0x64/0xe0
    driver_unregister+0x38/0x68
    platform_driver_unregister+0x1c/0x28
    scmi_driver_exit+0x38/0x44 [scmi_module]
   ---[ end trace 17bde19f50436de9 ]---
   Kernel panic - not syncing: Fatal exception
   SMP: stopping secondary CPUs
   Kernel Offset: 0x1d0000 from 0xffff800010000000
   PHYS_OFFSET: 0x80000000
   CPU features: 0x0240022,25806004
   Memory Limit: none
   ---[ end Kernel panic - not syncing: Fatal exception ]---

Link: https://lore.kernel.org/r/20200908112611.31515-1-sudeep.holla@arm.com
Fixes: 5c8a47a5 ("firmware: arm_scmi: Make scmi core independent of the transport type")
Cc: Cristian Marussi <cristian.marussi@arm.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: NCristian Marussi <cristian.marussi@arm.com>
Reviewed-by: NCristian Marussi <cristian.marussi@arm.com>
Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Add SCMI device for system power protocol by just adding the name "syspower"
to the list of supported core protocol devices.

Link: https://lore.kernel.org/r/20200907174657.32466-3-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Add bare protocol support for SCMI system power protocol as needed by
an OSPM agent: basic initialization and SYSTEM_POWER_STATE_NOTIFIER
core notification support.

No event-handling logic is attached to such notification..

Link: https://lore.kernel.org/r/20200907174657.32466-2-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

These are never modified, so make them const to allow the compiler to
put them in read-only memory.

Link: https://lore.kernel.org/r/20200906230452.33410-4-rikard.falkeborn@gmail.comSigned-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Add helpers to wrap the get_fs/set_fs magic for undoing any damange done
by set_fs(KERNEL_DS).  There is no real functional benefit, but this
documents the intent of these calls better, and will allow stubbing the
functions out easily for kernels builds that do not allow address space
overrides in the future.

[hch@lst.de: drop two incorrect hunks, fix a commit log typo]
  Link: http://lkml.kernel.org/r/20200714105505.935079-6-hch@lst.deSigned-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NGreentime Hu <green.hu@gmail.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: Nick Hu <nickhu@andestech.com>
Cc: Vincent Chen <deanbo422@gmail.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Link: http://lkml.kernel.org/r/20200710135706.537715-6-hch@lst.deSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

kobject_init_and_add() takes reference even when it fails.
If this function returns an error, kobject_put() must be called to
properly clean up the memory associated with the object.
Callback function fw_cfg_sysfs_release_entry() in kobject_put()
can handle the pointer "entry" properly.
Signed-off-by: NQiushi Wu <wu000273@umn.edu>
Link: https://lore.kernel.org/r/20200613190533.15712-1-wu000273@umn.eduSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>

This reverts commit 2d38dbf8 as it broke
the build in linux-next
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Fixes: 2d38dbf8 ("test_firmware: Test platform fw loading on non-EFI systems")
Cc: stable@vger.kernel.org
Cc: Scott Branden <scott.branden@broadcom.com>
Cc: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20200727165539.0e8797ab@canb.auug.org.auSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On non-EFI systems, it wasn't possible to test the platform firmware
loader because it will have never set "checked_fw" during __init.
Instead, allow the test code to override this check. Additionally split
the declarations into a private header file so it there is greater
enforcement of the symbol visibility.

Fixes: 548193cb ("test_firmware: add support for firmware_request_platform")
Cc: stable@vger.kernel.org
Acked-by: NScott Branden <scott.branden@broadcom.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20200724213640.389191-2-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for the Inline Crypto Engine (ICE) key programming interface
that's needed for the ufs-qcom driver to use inline encryption on
Snapdragon SoCs.  This interface consists of two SCM calls: one to program
a key into a keyslot, and one to invalidate a keyslot.

Although the UFS specification defines a standard way to do this, on these
SoCs the Linux kernel isn't permitted to access the needed crypto
configuration registers directly; these SCM calls must be used instead.

Link: https://lore.kernel.org/r/20200710072013.177481-2-ebiggers@kernel.orgAcked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
    For each line:
      If doesn't contain `\bxmlns\b`:
        For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
            If both the HTTP and HTTPS versions
            return 200 OK and serve the same content:
              Replace HTTP with HTTPS.
Signed-off-by: NAlexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>

The firmware on Turris MOX secure processor offers signing messages
with ECDSA private key stored in protected OTP memory.

The optimal solution would be to register an akcipher provider via
kernel's crypto API, but crypto API does not yet support accessing
akcipher API from userspace (and probably won't for some time, see
https://www.spinics.net/lists/linux-crypto/msg38388.html).

At first I tried to put this via standard sysfs API, but the way I
designed it is not compatible with sysfs's standard "one file per
attribute".

This patch therefore adds support for accessing this signature
generation mechanism via debugfs. Since CZ.NIC's Turris MOX is the only
user of this module, the potential future change to akcipher API should
not cause problems, since we can just change our userspace software then.
Signed-off-by: NMarek Behún <marek.behun@nic.cz>
Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>

Kbuild test robot reports the following sparse warning:

drivers/firmware/arm_scmi/clock.c:142:21:
	sparse: Using plain integer as NULL pointer

Use NULL pointer instead of integer 0 for rate pointer and fix the
warning.

Link: https://lore.kernel.org/r/20200717140405.17905-1-sudeep.holla@arm.comReported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Now that there's a function that calculates the SHA-256 digest of a
buffer in one step, use it instead of sha256_init() + sha256_update() +
sha256_final().
Reviewed-by: NArd Biesheuvel <ardb@kernel.org>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Cc: linux-efi@vger.kernel.org
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add support for retrieving BPMP debug information via in-band messaging
as opposed to using shared-memory which older BPMP firmware used. Note
that it is possible to detect at runtime whether the BPMP firmware being
used supports the in-band messaging for retrieving the debug
informaation. Therefore, if the BPMP firmware supports the in-band
messaging for debug use this and otherwise fall-back to using shared
memory.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Currently, BPMP debug information is accessible via the Linux debugfs
file-system using a shared-memory scheme. More recent BPMP firmware now
supports accessing the debug information by in-band messaging which does
not require shared-memory. To prepare for adding in-band debugfs support
for the BPMP, move the shared-memory specific initialisation from the
tegra_bpmp_init_debugfs() into a sub-function.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Most functions in the BPMP driver use 'err' as the return variable
name but there are a few places that use 'ret'. Let's use 'err' to
be consistent.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Add checking of the BPMP-FW return code values for MRQ_DEBUGFS calls.

Also, development versions of the firmware may have debugfs with a
directory structure larger than 256 KiB. Hence increase the size of the
memory buffer to accommodate those firmware revisions.

And finally, ensure that no access outside of allocated memory buffer
happens in case BPMP-FW returns an invalid response size (nbytes) from
mrq_debugfs_dumpdir() call.
Signed-off-by: NTimo Alho <talho@nvidia.com>
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This change adds a compatible for msm8994,
which requires no additional clocks for
scm to probe correctly.
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NKonrad Dybcio <konradybcio@gmail.com>
Link: https://lore.kernel.org/r/20200624150107.76234-2-konradybcio@gmail.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The move to a combined driver for the QCOM SCM hardware changed the
io_writel and io_readl helpers to use non-atomic calls, despite the
commit message saying that atomic was a better option. This breaks these
helpers on hardware that uses the old legacy convention (access fails
with a -95 return code). Switch back to using the atomic calls.

Observed as a failure routing GPIO interrupts to the Apps processor on
an IPQ8064; fix is confirmed as correctly allowing the interrupts to be
routed and observed.
Reviewed-by: NElliot Berman <eberman@codeaurora.org>
Fixes: 57d3b816 ("firmware: qcom_scm: Remove thin wrappers")
Cc: stable@vger.kernel.org
Signed-off-by: NJonathan McDowell <noodles@earth.li>
Link: https://lore.kernel.org/r/20200704172334.GA759@earth.liSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Since commit 82046702 ("efi/libstub/arm64: Replace 'preferred' offset
with alignment check"), loading a relocatable arm64 kernel at a physical
address which is not 2MB aligned and subsequently booting with EFI will
leave the Image in-place, relying on the kernel to relocate itself early
during boot. In conjunction with commit dd4bc607 ("arm64: warn on
incorrect placement of the kernel by the bootloader"), which enables
CONFIG_RELOCATABLE by default, this effectively means that entering an
arm64 kernel loaded at an alignment smaller than 2MB with EFI (e.g. using
QEMU) will result in silent relocation at runtime.

Unfortunately, this has a subtle but confusing affect for developers
trying to inspect the PC value during a crash and comparing it to the
symbol addresses in vmlinux using tools such as 'nm' or 'addr2line';
all text addresses will be displaced by a sub-2MB offset, resulting in
the wrong symbol being identified in many cases. Passing "nokaslr" on
the command line or disabling "CONFIG_RANDOMIZE_BASE" does not help,
since the EFI stub only copies the kernel Image to a 2MB boundary if it
is not relocatable.

Adjust the EFI stub for arm64 so that the minimum Image alignment is 2MB
unless KASLR is in use.

Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: David Brazdil <dbrazdil@google.com>
Acked-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NWill Deacon <will@kernel.org>

Event reports are used to convey information describing events to the
registered user-callbacks: they are necessarily derived from the underlying
raw SCMI events' messages but they are not meant to expose or directly
mirror any of those messages data layout, which belong to the protocol
layer.

Using fixed size types for report fields, mirroring messages structure,
is at odd with this: get rid of them using more generic, equivalent,
typing.

Substitute scmi_event_header fixed size fields with generic types too and
shuffle around fields definitions to minimize implicit padding while
adapting involved functions.

Link: https://lore.kernel.org/r/20200710133919.39792-3-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Remove __packed attribute from struct scmi_event_header.

Link: https://lore.kernel.org/r/20200710133919.39792-2-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

gcc as well as clang now produce warnings for missing kerneldoc function
parameter.

Fix the following W=1 kernel build warning:

drivers/firmware/arm_scmi/smc.c:32:
 warning: Function parameter or member 'shmem_lock' not described in 'scmi_smc'

Link: https://lore.kernel.org/r/20200709153155.22573-1-sudeep.holla@arm.comReported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

The i.MX SCU soc driver depends on SCU firmware driver, so it has to
use platform driver model for proper defer probe operation, since
it has no device binding in DT file, a simple platform device is
created together inside the platform driver. To make it more clean,
we can just move the entire SCU soc driver into imx firmware folder
and initialized by i.MX SCU firmware driver.
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

Instead of relying on the firmware to keep the clock rates sorted, let
us sort the list. This is not essential for clock layer but it helps
to find the min and max rates easily from the list.

Link: https://lore.kernel.org/r/20200709081705.46084-1-sudeep.holla@arm.com
Fixes: 5f6c6430 ("firmware: arm_scmi: add initial support for clock protocol")
Reported-and-tested-by: NDien Pham <dien.pham.ry@renesas.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

This reverts commit 5435f73d, which is no longer needed now
that the minimum GCC version has been bumped to v4.9
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

Commit

  bf67fad1 ("efi: Use more granular check for availability for variable services")

introduced a check into the efivarfs, efi-pstore and other drivers that
aborts loading of the module if not all three variable runtime services
(GetVariable, SetVariable and GetNextVariable) are supported. However, this
results in efivarfs being unavailable entirely if only SetVariable support
is missing, which is only needed if you want to make any modifications.
Also, efi-pstore and the sysfs EFI variable interface could be backed by
another implementation of the 'efivars' abstraction, in which case it is
completely irrelevant which services are supported by the EFI firmware.

So make the generic 'efivars' abstraction dependent on the availibility of
the GetVariable and GetNextVariable EFI runtime services, and add a helper
'efivar_supports_writes()' to find out whether the currently active efivars
abstraction supports writes (and wire it up to the availability of
SetVariable for the generic one).

Then, use the efivar_supports_writes() helper to decide whether to permit
efivarfs to be mounted read-write, and whether to enable efi-pstore or the
sysfs EFI variable interface altogether.

Fixes: bf67fad1 ("efi: Use more granular check for availability for variable services")
Reported-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

The prototype of the functions handle_kernel_image & efi_enter_kernel
are defined in efi-stub.c which may result in a compiler warnings if
-Wmissing-prototypes is set in gcc compiler.

Move the prototype to efistub.h to make the compiler happy.
Signed-off-by: NAtish Patra <atish.patra@wdc.com>
Link: https://lore.kernel.org/r/20200706172609.25965-2-atish.patra@wdc.comSigned-off-by: NArd Biesheuvel <ardb@kernel.org>

32bit gcc doesn't support modulo operation on 64 bit data. It results in
a __umoddi3 error while building EFI for 32 bit.

Use bitwise operations instead of modulo operations to fix the issue.
Signed-off-by: NAtish Patra <atish.patra@wdc.com>
Link: https://lore.kernel.org/r/20200625234516.31406-2-atish.patra@wdc.comSigned-off-by: NArd Biesheuvel <ardb@kernel.org>

The return value of down_and_up_cpus() can be assigned to @err directly.
With that, the useless assignment to @err with zero can be dropped.
Signed-off-by: NGavin Shan <gshan@redhat.com>
Reviewed-by: NSudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/20200630075943.203954-1-gshan@redhat.comSigned-off-by: NWill Deacon <will@kernel.org>

The CPU mask (@tmp) should be released on failing to allocate
@cpu_groups or any of its elements. Otherwise, it leads to memory
leakage because the CPU mask variable is dynamically allocated
when CONFIG_CPUMASK_OFFSTACK is enabled.
Signed-off-by: NGavin Shan <gshan@redhat.com>
Reviewed-by: NSudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/20200630075227.199624-1-gshan@redhat.comSigned-off-by: NWill Deacon <will@kernel.org>

Some Makefiles already pass -ffreestanding unconditionally.
For example, arch/arm64/lib/Makefile, arch/x86/purgatory/Makefile.

No problem report so far about hard-coding this option. So, we can
assume all supported compilers know -ffreestanding.

I confirmed GCC 4.8 and Clang manuals document this option.

Get rid of cc-option from -ffreestanding.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Acked-by: NArd Biesheuvel <ardb@kernel.org>

Some Makefiles already pass -fno-stack-protector unconditionally.
For example, arch/arm64/kernel/vdso/Makefile, arch/x86/xen/Makefile.

No problem report so far about hard-coding this option. So, we can
assume all supported compilers know -fno-stack-protector.

GCC 4.8 and Clang support this option (https://godbolt.org/z/_HDGzN)

Get rid of cc-option from -fno-stack-protector.

Remove CONFIG_CC_HAS_STACKPROTECTOR_NONE, which is always 'y'.

Note:
arch/mips/vdso/Makefile adds -fno-stack-protector twice, first
unconditionally, and second conditionally. I removed the second one.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Acked-by: NArd Biesheuvel <ardb@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

SMCCC v1.2 adds a new optional function SMCCC_ARCH_SOC_ID to obtain a
SiP defined SoC identification value. Add support for the same.

Also using the SoC bus infrastructure, let us expose the platform
specific SoC atrributes under sysfs.

There are various ways in which it can be represented in shortened form
for efficiency and ease of parsing for userspace. The chosen form is
described in the ABI document.

Link: https://lore.kernel.org/r/20200625095939.50861-1-sudeep.holla@arm.com
Cc: Etienne Carriere <etienne.carriere@st.com>
Reviewed-by: NSteven Price <steven.price@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Patch fixes sparse warnings: using plain integer as NULL pointer. Replaces
equal to with logical not operator.
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NRichard Gong <richard.gong@intel.com>
Link: https://lore.kernel.org/r/1591193212-15082-1-git-send-email-richard.gong@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Extend Intel Remote System Update (RSU) driver to get decision
configuration management firmware (DCMF) versions and max retry
parameter value.
Signed-off-by: NRichard Gong <richard.gong@intel.com>
Link: https://lore.kernel.org/r/1592231348-31334-4-git-send-email-richard.gong@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Extend Intel Stratix10 service layer driver to support new RSU DCMF
versions and max retry parameter.

DCMF = Decision Configuration Management Firmware. The max retry parameter
is the maximum times the images is allowed to reload itself before giving
up and starting RSU failover flow.
Signed-off-by: NRichard Gong <richard.gong@intel.com>
Link: https://lore.kernel.org/r/1592231348-31334-3-git-send-email-richard.gong@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make SCMI base protocol register with the notification core.

Link: https://lore.kernel.org/r/20200701155348.52864-10-cristian.marussi@arm.comReviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>