The Qualcomm Secure Channel Manager (SCM) is only present on Qualcomm
SoCs.  All drivers using it select QCOM_SCM, and depend on ARCH_QCOM.
Until recently, QCOM_SCM was an invisible symbol, but this was changed
by adding loadable module support, exposing it to all ARM and ARM64
users.  Hence add a dependency on ARCH_QCOM, to prevent asking the user
about this driver when configuring a kernel without Qualcomm SoC
support.

While at it, drop the dependency on ARM || ARM64, as that is implied by
HAVE_ARM_SMCCC.

Fixes: b42000e4 ("firmware: qcom_scm: Allow qcom_scm driver to be loadable as a permenent module")
Fixes: 2954a6f1 ("firmware: qcom-scm: Fix QCOM_SCM configuration")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/5cda77085c07dc2e8d2195507b287457cb2f09e9.1629807831.git.geert+renesas@glider.be

Add configuration options to be able to select which SCMI transports have
to be compiled into the SCMI stack.

Mailbox and SMC are by default enabled if their related dependencies are
satisfied.

While doing that move all SCMI related config options in their own
dedicated submenu.

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

The Generic System Framebuffers support is built when the COMPILE_TEST
option is enabled. But this wrongly assumes that all the architectures
declare a struct screen_info.

This is true for most architectures, but at least the following do not:
arc, m68k, microblaze, openrisc, parisc and s390.

By attempting to make this compile testeable on all architectures, it
leads to linking errors as reported by the kernel test robot for parisc:

  All errors (new ones prefixed by >>):

     hppa-linux-ld: drivers/firmware/sysfb.o: in function `sysfb_init':
     (.init.text+0x24): undefined reference to `screen_info'
  >> hppa-linux-ld: (.init.text+0x28): undefined reference to `screen_info'

To prevent these errors only allow sysfb to be built on systems that are
going to need it, which are x86 BIOS and EFI.

The EFI Kconfig symbol is used instead of (ARM || ARM64 || RISC) because
some of these architectures only declare a struct screen_info if EFI is
enabled. And also, because the SYSFB code is only used for EFI on these
architectures. For !EFI the "simple-framebuffer" device is registered by
OF when parsing the Device Tree Blob (if a DT node for this was defined).

Fixes: d391c582 ("drivers/firmware: move x86 Generic System Framebuffers support")
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210727093015.1225107-1-javierm@redhat.com

The register_gop_device() function registers an "efi-framebuffer" platform
device to match against the efifb driver, to have an early framebuffer for
EFI platforms.

But there is already support to do exactly the same by the Generic System
Framebuffers (sysfb) driver. This used to be only for X86 but it has been
moved to drivers/firmware and could be reused by other architectures.

Also, besides supporting registering an "efi-framebuffer", this driver can
register a "simple-framebuffer" allowing to use the siple{fb,drm} drivers
on non-X86 EFI platforms. For example, on aarch64 these drivers can only
be used with DT and doesn't have code to register a "simple-frambuffer"
platform device when booting with EFI.

For these reasons, let's remove the register_gop_device() duplicated code
and instead move the platform specific logic that's there to sysfb driver.
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Acked-by: NBorislav Petkov <bp@suse.de>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210625131359.1804394-1-javierm@redhat.com

The x86 architecture has generic support to register a system framebuffer
platform device. It either registers a "simple-framebuffer" if the config
option CONFIG_X86_SYSFB is enabled, or a legacy VGA/VBE/EFI FB device.

But the code is generic enough to be reused by other architectures and can
be moved out of the arch/x86 directory.

This will allow to also support the simple{fb,drm} drivers on non-x86 EFI
platforms, such as aarch64 where these drivers are only supported with DT.
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Acked-by: NBorislav Petkov <bp@suse.de>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210625130947.1803678-2-javierm@redhat.com

Allow the qcom_scm driver to be loadable as a permenent module.

This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to
ensure that drivers that call into the qcom_scm driver are
also built as modules. While not ideal in some cases its the
only safe way I can find to avoid build errors without having
those drivers select QCOM_SCM and have to force it on (as
QCOM_SCM=n can be valid for those drivers).

Reviving this now that Saravana's fw_devlink defaults to on,
which should avoid loading troubles seen before.
Acked-by: NKalle Valo <kvalo@codeaurora.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NWill Deacon <will@kernel.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/20210707045320.529186-1-john.stultz@linaro.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

ARM_SCMI_PROTOCOL depends on either MAILBOX or HAVE_ARM_SMCCC_DISCOVERY,
not MAILBOX alone. Fix the depedency in Kconfig file and driver to
reflect the same.

Link: https://lore.kernel.org/r/20210521134055.24271-1-etienne.carriere@linaro.orgReviewed-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NEtienne Carriere <etienne.carriere@linaro.org>
[sudeep.holla: Minor tweaks to subject and change log]
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

The Arm FF for Armv8-A specification has concept of endpoints or
partitions. In the Normal world, a partition could be a VM when
the Virtualization extension is enabled or the kernel itself.

In order to handle multiple partitions, we can create a FFA device for
each such partition on a dedicated FFA bus. Similarly, different drivers
requiring FFA transport can be registered on the same bus. We can match
the device and drivers using UUID. This is mostly for the in-kernel
users with FFA drivers.

Link: https://lore.kernel.org/r/20210521151033.181846-2-sudeep.holla@arm.comTested-by: NJens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

When CONFIG_QCOM_SCM is y and CONFIG_HAVE_ARM_SMCCC
is not set, compiling errors are encountered as follows:

drivers/firmware/qcom_scm-smc.o: In function `__scm_smc_do_quirk':
qcom_scm-smc.c:(.text+0x36): undefined reference to `__arm_smccc_smc'
drivers/firmware/qcom_scm-legacy.o: In function `scm_legacy_call':
qcom_scm-legacy.c:(.text+0xe2): undefined reference to `__arm_smccc_smc'
drivers/firmware/qcom_scm-legacy.o: In function `scm_legacy_call_atomic':
qcom_scm-legacy.c:(.text+0x1f0): undefined reference to `__arm_smccc_smc'

Note that __arm_smccc_smc is defined when HAVE_ARM_SMCCC is y.
So add dependency on HAVE_ARM_SMCCC in QCOM_SCM configuration.

Fixes: 916f743d ("firmware: qcom: scm: Move the scm driver to drivers/firmware")
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NHe Ying <heying24@huawei.com>
Link: https://lore.kernel.org/r/20210406094200.60952-1-heying24@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Stratix10 service layer and RCU drivers are useful only on
Stratix10, so on ARMv8.  Compile testing the RCU driver on 32-bit ARM
fails:

  drivers/firmware/stratix10-rsu.c: In function 'rsu_status_callback':
  include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_179'
    declared with attribute error: FIELD_GET: type of reg too small for mask
    _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
  ...
  drivers/firmware/stratix10-rsu.c:96:26: note: in expansion of macro 'FIELD_GET'
    priv->status.version = FIELD_GET(RSU_VERSION_MASK,

Fixes: 4483397b ("ARM: socfpga: drop ARCH_SOCFPGA")
Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Acked-by: NRichard Gong <richard.gong@linux.intel.com>
Signed-off-by: NDinh Nguyen <dinguyen@kernel.org>
---
v2: add Fixes tag

Agilex, N5X and Stratix 10 share all quite similar arm64 hard cores and
SoC-part.  Up to a point that N5X uses the same DTSI as Agilex.  From
the Linux kernel point of view these are flavors of the same
architecture so there is no need for three top-level arm64
architectures.  Simplify this by merging all three architectures into
ARCH_INTEL_SOCFPGA and dropping the other ARCH* arm64 Kconfig entries.

The side effect is that the INTEL_STRATIX10_SERVICE will now be
available for both 32-bit and 64-bit Intel SoCFPGA, even though it is
used only for 64-bit.
Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: NDinh Nguyen <dinguyen@kernel.org>

There is a spelling mistake in the Kconfig help text. Fix it.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20201204192250.1151316-1-colin.king@canonical.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit d0511b54.

After some time it was noticed that the Tegra186 among others
were experiencing problems when making this into a module.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Allow the qcom_scm driver to be loadable as a permenent module.

This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to
ensure that drivers that call into the qcom_scm driver are
also built as modules. While not ideal in some cases its the
only safe way I can find to avoid build errors without having
those drivers select QCOM_SCM and have to force it on (as
QCOM_SCM=n can be valid for those drivers).
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NKalle Valo <kvalo@codeaurora.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: Maulik Shah <mkshah@codeaurora.org>
Cc: Lina Iyer <ilina@codeaurora.org>
Cc: Saravana Kannan <saravanak@google.com>
Cc: Todd Kjos <tkjos@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: iommu@lists.linux-foundation.org
Cc: linux-gpio@vger.kernel.org
Link: https://lore.kernel.org/r/20201106042710.55979-3-john.stultz@linaro.orgSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>

Signed-off-by: NHelge Deller <deller@gmx.de>

Now, with all the plumbing in place to enable building scmi as a module
instead of built-in modules, let us enable the same.

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

This reverts commit c65822fe.

The initialization of Raspberry Pi 4's USB chip is now handled through a
reset controller. No need to directly call the firmware routine through a
PCI quirk.
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Link: https://lore.kernel.org/r/20200629161845.6021-7-nsaenzjulienne@suse.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

SMCCC v1.0 lacked discoverability of version and features. To accelerate
adoption of few mitigations and protect systems more rapidly from various
vulnerability, PSCI v1.0 was updated to add SMCCC discovery mechanism
though the PSCI firmware implementation of PSCI_FEATURES(SMCCC_VERSION)
which returns success on firmware compliant to SMCCC v1.1 and above.

This inturn makes SMCCC v1.1 and above dependent on ARM_PSCI_FW for
backward compatibility. Let us introduce a new hidden config for the
same to build more features on top of SMCCC v1.1 and above.

While at it, also sort alphabetically the psci entry.
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Tested-by: NEtienne Carriere <etienne.carriere@st.com>
Reviewed-by: NEtienne Carriere <etienne.carriere@st.com>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20200518091222.27467-2-sudeep.holla@arm.comSigned-off-by: NWill Deacon <will@kernel.org>

On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
loaded directly from an EEPROM or, if not present, by the SoC's
VideoCore. Inform VideoCore that VL805 was just reset.

Also, as this creates a dependency between USB_PCI and VideoCore's
firmware interface, and since USB_PCI can't be set as a module neither
this can. Reflect that on the firmware interface Kconfg.

Link: https://lore.kernel.org/r/20200505161318.26200-5-nsaenzjulienne@suse.deSigned-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com>

Add depend on Agilex for Intel Agilex SoC platform.
Signed-off-by: NRichard Gong <richard.gong@intel.com>
Acked-by: NMoritz Fischer <mdf@kernel.org>
Link: https://lore.kernel.org/r/1583428346-13307-3-git-send-email-richard.gong@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Dynamically support SMCCCC and legacy conventions by detecting which
convention to use at runtime. qcom_scm_call_atomic and qcom_scm_call can
then be moved in qcom_scm.c and use underlying convention backend as
appropriate. Thus, rename qcom_scm-64,-32 to reflect that they are
backends for -smc and -legacy, respectively.

Also add support for making SCM calls earlier than when SCM driver
probes to support use cases such as qcom_scm_set_cold_boot_addr. Support
is added by lazily initializing the convention and guarding the query
with a spin lock.  The limitation of these early SCM calls is that they
cannot use DMA, as in the case of >4 arguments for SMC convention and
any non-atomic call for legacy convention.

Tested-by: Brian Masney <masneyb@onstation.org> # arm32
Tested-by: NStephan Gerhold <stephan@gerhold.net>
Signed-off-by: NElliot Berman <eberman@codeaurora.org>
Link: https://lore.kernel.org/r/1578431066-19600-18-git-send-email-eberman@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

This adds a driver to communicate with the firmware running on the
secure processor of the Turris Mox router, enabling the kernel to
retrieve true random numbers from the Entropy Bit Generator and to read
some information burned into eFuses when device was manufactured:

and to
sign messages with the ECDSA private key burned into each Turris Mox
device when manufacturing.

This also adds support to read other information burned into eFuses:
 - serial number
 - board version
 - MAC addresses
 - RAM size
 - ECDSA public key (this is not read directly from eFuses, rather it
   is computed by the firmware as pair to the burned private key)

The source code of the firmware is open source and can be found at
https://gitlab.labs.nic.cz/turris/mox-boot-builder/tree/master/wtmi

The firmware is also able to, on demand, sign messages with the burned
ECDSA private key, but since Linux's akcipher API is not yet stable
(and therefore not exposed to userspace via netlink), this functionality
is not supported yet.

Link: https://lore.kernel.org/r/20190822014318.19478-3-marek.behun@nic.czSigned-off-by: NMarek Behún <marek.behun@nic.cz>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The Intel Remote System Update (RSU) driver exposes interfaces access
through the Intel Service Layer to user space via sysfs interface.
The RSU interfaces report and control some of the optional RSU features
on Intel Stratix 10 SoC.

The RSU feature provides a way for customers to update the boot
configuration of a Intel Stratix 10 SoC device with significantly reduced
risk of corrupting the bitstream storage and bricking the system.
Signed-off-by: NRichard Gong <richard.gong@intel.com>
Reviewed-by: NAlan Tull <atull@kernel.org>
Link: https://lore.kernel.org/r/1567516701-26026-3-git-send-email-richard.gong@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

iscsi_ibft can use ACPI to find the iBFT entry during bootup,
currently, ISCSI_IBFT depends on ISCSI_IBFT_FIND which is
a X86 legacy way to find the iBFT by searching through the
low memory. This patch changes the dependency so that other
arch like ARM64 can use ISCSI_IBFT as long as the arch supports
ACPI.

ibft_init() needs to use the global variable ibft_addr declared
in iscsi_ibft_find.c. A #ifndef CONFIG_ISCSI_IBFT_FIND is needed
to declare the variable if CONFIG_ISCSI_IBFT_FIND is not selected.
Moving ibft_addr into the iscsi_ibft.c does not work because if
ISCSI_IBFT is selected as a module, the arch/x86/kernel/setup.c won't
be able to find the variable at compile time.
Signed-off-by: NThomas Tai <thomas.tai@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The "+sec" extension is invalid for older ARM architectures, but
the code can now be built on any ARM configuration:

/tmp/trusted_foundations-2d0882.s: Assembler messages:
/tmp/trusted_foundations-2d0882.s:194: Error: architectural extension `sec' is not allowed for the current base architecture
/tmp/trusted_foundations-2d0882.s:201: Error: selected processor does not support `smc #0' in ARM mode
/tmp/trusted_foundations-2d0882.s:213: Error: architectural extension `sec' is not allowed for the current base architecture
/tmp/trusted_foundations-2d0882.s:220: Error: selected processor does not support `smc #0' in ARM mode

Add a dependency on ARMv7 for the build.

Fixes: 4cb5d9ec ("firmware: Move Trusted Foundations support")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The kbuild documentation clearly shows that the documents
there are written at different times: some use markdown,
some use their own peculiar logic to split sections.

Convert everything to ReST without affecting too much
the author's style and avoiding adding uneeded markups.

The conversion is actually:
  - add blank lines and identation in order to identify paragraphs;
  - fix tables markups;
  - add some lists markups;
  - mark literal blocks;
  - adjust title markups.

At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Add SPDX license identifiers to all Make/Kconfig files which:

 - Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move the Trusted Foundations support out of arch/arm/firmware and into
drivers/firmware where most other firmware support implementations are
located.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Some following changes extends the PSCI driver with some additional
files.  Avoid to continue cluttering the toplevel firmware directory
and first move the PSCI files into a PSCI sub-directory.
Suggested-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This does not build yet ...

Cc: Richard Gong <richard.gong@intel.com>
Fixes: 095ff29d ("firmware: intel_stratix10_service: add hardware dependency")
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add a Kconfig dependency to ensure Intel Stratix10 service layer driver
can be built only on the platform that supports it.
Signed-off-by: NRichard Gong <richard.gong@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some features of the Intel Stratix10 SoC require a level of privilege
higher than the kernel is granted. Such secure features include
FPGA programming. In terms of the ARMv8 architecture, the kernel runs
at Exception Level 1 (EL1), access to the features requires
Exception Level 3 (EL3).

The Intel Stratix10 SoC service layer provides an in kernel API for
drivers to request access to the secure features. The requests are queued
and processed one by one. ARM’s SMCCC is used to pass the execution
of the requests on to a secure monitor (EL3).

The header file stratix10-sve-client.h defines the interface between
service providers (FPGA manager is one of them) and service layer.

The header file stratix10-smc.h defines the secure monitor call (SMC)
message protocols used for service layer driver in normal world
(EL1) to communicate with secure monitor SW in secure monitor exception
level 3 (EL3).
Signed-off-by: NRichard Gong <richard.gong@intel.com>
Signed-off-by: NAlan Tull <atull@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The System Controller Firmware (SCFW) is a low-level system function
which runs on a dedicated Cortex-M core to provide power, clock, and
resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
(QM, QP), and i.MX8QX (QXP, DX).

This patch implements the SCU firmware IPC function and the common
message sending API sc_call_rpc.

Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Reviewed-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

Move dcdbas to the more appropriate directory drivers/platform/x86.
Signed-off-by: NStuart Hayes <stuart.w.hayes@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Move dell_rbu to the more appropriate directory drivers/platform/x86.
Signed-off-by: NStuart Hayes <stuart.w.hayes@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

This patch is adding communication layer with firmware.
Firmware driver provides an interface to firmware APIs.
Interface APIs can be used by any driver to communicate to
PMUFW(Platform Management Unit). All requests go through ATF.
Signed-off-by: NRajan Vaja <rajanv@xilinx.com>
Signed-off-by: NJolly Shah <jollys@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

This patch hooks up the support for device power domain provided by
SCMI using the Linux generic power domain infrastructure.

Cc: Kevin Hilman <khilman@baylibre.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

The SCMI is intended to allow OSPM to manage various functions that are
provided by the hardware platform it is running on, including power and
performance functions. SCMI provides two levels of abstraction, protocols
and transports. Protocols define individual groups of system control and
management messages. A protocol specification describes the messages
that it supports. Transports describe the method by which protocol
messages are communicated between agents and the platform.

This patch adds basic infrastructure to manage the message allocation,
initialisation, packing/unpacking and shared memory management.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

I ran into a build error for the psci_checker:

drivers/firmware/psci_checker.o: In function `psci_checker':
psci_checker.c:(.init.text+0x528): undefined reference to `cpuidle_devices'

As far as I can tell, this is simply a very rare combination of options,
but the problem has existed since the code was initially added.
Adding a Kconfig dependency makes it build properly.

Fixes: ea8b1c4a ("drivers: psci: PSCI checker module")
Acked-by: NKevin Brodsky <kevin.brodsky@arm.com>
Reviewed-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The Software Delegated Exception Interface (SDEI) is an ARM standard
for registering callbacks from the platform firmware into the OS.
This is typically used to implement firmware notifications (such as
firmware-first RAS) or promote an IRQ that has been promoted to a
firmware-assisted NMI.

Add the code for detecting the SDEI version and the framework for
registering and unregistering events. Subsequent patches will add the
arch-specific backend code and the necessary power management hooks.

Only shared events are supported, power management, private events and
discovery for ACPI systems will be added by later patches.
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>