Add new GSMI commands (GSMI_CMD_LOG_S0IX_SUSPEND = 0xa,
GSMI_CMD_LOG_S0IX_RESUME = 0xb) that allow firmware to log any
information during S0ix suspend/resume paths.
Traditional ACPI suspend S3 involves BIOS both during the suspend and
the resume paths. However, modern suspend type like S0ix does not
involve firmware on either of the paths. This command gives the
firmware an opportunity to log any required information about the
suspend and resume operations e.g. wake sources.
Additionally, this change adds a module parameter to allow platforms
to specifically enable S0ix logging if required. This prevents any
other platforms from unnecessarily making a GSMI call which could have
any side-effects.
Tested by verifying that wake sources are correctly logged in eventlog.
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Rajat Jain <rajatja@chromium.org>
Signed-off-by: Furquan Shaikh <furquan@google.com>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
[zwisler: update changelog for upstream]
Signed-off-by: Ross Zwisler <zwisler@google.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Instead of selecting EFI and EFI_VARS automatically when GSMI is
enabled let that portion of the driver be conditionally compiled
if EFI and EFI_VARS are enabled.
This allows the rest of the driver (specifically event log) to
be used if EFI_VARS is not enabled.
To test:
1) verify that EFI_VARS is not automatically selected when
CONFIG_GOOGLE_GSMI is enabled
2) verify that the kernel boots on Link and that GSMI event log
is still available and functional
3) specifically boot the kernel on Alex to ensure it does not
try to load efivars and that gsmi also does not load because it
is not in the supported DMI table
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Ben Zhang <benzh@chromium.org>
Signed-off-by: Filipe Brandenburger <filbranden@chromium.org>
Signed-off-by: Furquan Shaikh <furquan@google.com>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
[zwisler: update changelog for upstream]
Signed-off-by: Ross Zwisler <zwisler@google.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The sysfs handler should return the number of bytes consumed, which in the
case of a successful write is the entire buffer. Also fix a bug where
param.data_len was being set to (count - (2 * sizeof(u32))) instead of just
(count - sizeof(u32)). The latter is correct because we skip over the
leading u32 which is our param.type, but we were also incorrectly
subtracting sizeof(u32) on the line where we were actually setting
param.data_len:
param.data_len = count - sizeof(u32);
This meant that for our example event.kernel_software_watchdog with total
length 10 bytes, param.data_len was just 2 prior to this change.
To test, successfully append an event to the log with gsmi sysfs.
This sample event is for a "Kernel Software Watchdog"
> xxd -g 1 event.kernel_software_watchdog
0000000: 01 00 00 00 ad de 06 00 00 00
> cat event.kernel_software_watchdog > /sys/firmware/gsmi/append_to_eventlog
> mosys eventlog list | tail -1
14 | 2012-06-25 10:14:14 | Kernl Event | Software Watchdog
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Furquan Shaikh <furquan@google.com>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
[zwisler: updated changelog for 2nd bug fix and upstream]
Signed-off-by: Ross Zwisler <zwisler@google.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This contains a fix for suspend/resume support for the BPMP found on
Tegra186 and Tegra194.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlu/HeITHHRyZWRpbmdA
bnZpZGlhLmNvbQAKCRDdI6zXfz6zoepqD/0T8hWZPlURebJO3cTDkaI2kpA+gmG+
GK/K+9AmvtEPhJXN32QUDk8MjMnVXjeWCOMdN4Agm6KedVrQI3nKQ6RuuUwF4AbR
yI5RxnU4NpTP/Xchr7rL8d/S0Yd7nWheOcU2KHMQBYmu2SEtYKJO6xpfHwZZDow3
2gvjPAdu4PsxbJRh4FiXLkO7AFMztlrzCgWJ7IodwM98ys2lY5jp/5eLn3/WwIjA
7TC2fCqr0WmHWJmfRxuffgMxFimFk0MZEF81Or40ZCFImGoRQFhdxvWKcuj2wPTJ
LHKcpqf0ES6untGWTAO4WeOcpxgTzw2Rqtn6qvoM2vlJoFYdBV8h0bz8sfrEA06f
IT5dbetaC1k7j4Y58+GDFSYXYvwHcJe2EEZnjPP4jILGTIw8JChAOjmTHlgz/oxg
ct4eeWJ2wT18rOQNdkz+yd4l/VYR0lAyTo5DN1MBxAd3iq5UMMvrtDq5wUIYN9kY
zs02Z+2MyYTmDFIIUwS2vS6HMkqOCWnZ1J6z4hGgOM+lbjzF43ducWgXI8VesK6m
LAiQmHikvAKcVIlQzP1RuMCpI8+GSx0rawLUJy77wdctaBX2cXr6i4zxA11rqOnO
DUYRFtHP9oFPolOhzEA8QWLFpoFvLfYBHNrBYl7e0tWdrP17IruQK2xIXXQtRyep
vdFG7A1lJ+7bEg==
=uZkB
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-4.20-firmware-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers
firmware: tegra: Changes for v4.20-rc1
This contains a fix for suspend/resume support for the BPMP found on
Tegra186 and Tegra194.
* tag 'tegra-for-4.20-firmware-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
firmware: tegra: bpmp: Implement suspend/resume support
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
When returning from a system sleep state, the BPMP driver needs to
reinitialize the IVC channels used to communicate with the BPMP to
restore proper functionality.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This patchset adds CCF compliant clock driver for ZynqMP.
Clock driver queries supported clock information from firmware
and regiters pll and output clocks with CCF.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEABECAAYFAlu8k7oACgkQykllyylKDCFmPACfewJHUsKUhaX77Ew+Pup5tFzC
GHgAn1Xb2fJF+9D4CSB+iwdQNPltuhBg
=QShK
-----END PGP SIGNATURE-----
Merge tag 'zynqmp-soc-clk-for-v4.20' of https://github.com/Xilinx/linux-xlnx into next/drivers
arm64: zynqmp: SoC CLK changes for v4.20
This patchset adds CCF compliant clock driver for ZynqMP.
Clock driver queries supported clock information from firmware
and regiters pll and output clocks with CCF.
* tag 'zynqmp-soc-clk-for-v4.20' of https://github.com/Xilinx/linux-xlnx:
drivers: clk: Add ZynqMP clock driver
dt-bindings: clock: Add bindings for ZynqMP clock driver
firmware: xilinx: Add zynqmp IOCTL API for device control
Documentation: xilinx: Add documentation for eemi APIs
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- A series from Aisheng Dong to add SCU firmware driver for i.MX8
SoCs. It implements IPC mechanism based on mailbox for message
exchange between AP and SCU firmware, and a set of SCU IPC
service APIs used by clients like i.MX8 power domain and clock
drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJbu28SAAoJEFBXWFqHsHzOjMYIAI67+hAik09NkEQKovKjJCDz
N6k1XzY0LJl1tvaQ8x/txmp0l/4yosr8eWr+Lp+rhNrO0B48WmAccqnhaXpm2esZ
6NqBOMWt32Rue08dscaCaz5/SJHjzUlvkzjKbeMrwe/UZZWY3jn16fxqDknINjq4
Zout0CyD4Dwh9AYPDbayVGnWb68BtiZvgFch99GP3pJnK5hzH7uYpLlGTmbpDn5S
4uRVUtXOn/Y+ADhNORDjeP6t4DnLDnEQ5QpTyjYxryd4Su/yiLih41UeyqvfEyQ4
hLxdkve+JNWQpbfcE1F1Sz6yM+nb33Or0PNzsIaTV9jtNSozwoRLqa79OKD4oAA=
=x2CN
-----END PGP SIGNATURE-----
Merge tag 'imx-drivers-4.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into next/drivers
i.MX drivers change for 4.20, round 2:
- A series from Aisheng Dong to add SCU firmware driver for i.MX8
SoCs. It implements IPC mechanism based on mailbox for message
exchange between AP and SCU firmware, and a set of SCU IPC
service APIs used by clients like i.MX8 power domain and clock
drivers.
* tag 'imx-drivers-4.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
MAINTAINERS: imx: include drivers/firmware/imx path
firmware: imx: add misc svc support
firmware: imx: add SCU firmware driver support
dt-bindings: arm: fsl: add scu binding doc
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add ZynqMP firmware IOCTL API to control and configure
devices like PLLs, SD, Gem, etc.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
Signed-off-by: Jolly Shah <jollys@xilinx.com>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
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: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
* Refactor of SCM compatibles and clock requirements
* SMEM cleanup
* Add LLCC EDAC driver
* Fixes for GENI clocks and macros
* Fix includes for llcc-slice and smem
* String overflow fixes for APR and wcnss_ctrl
* Fixup for COMPILE_TEST of qcom driver Kconfigs
* Cleanup of Kconfig depends of rpmh, smd_rpm, smsm, and smp2p
* Add SCM dependencies to SPM and rmtfs-mem
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJbsQupAAoJEFKiBbHx2RXVQBYQAKWr3RsQlWJ09M0vm8qGeCCA
8FXxX9wqcU34KvYR16IIXzQ/25L4h1uLjvjBfQurn7zOFIrCoqn2PGOchGOyJEA0
hPw+RomT17BV1hRSJkl8lIXMqGCAvoc44VrAQyipCTpEJO82emh6qJ1ki5XpIvfI
EOad6S2IGNXU39F0B6rtl4+LL/Vfh+MOJcz0E23SVujtDT0pvxuP5aVGM+Faqif/
rQ4dKcYZokRHmuTlfg2azo4OmkLyrwsMjirna3NN3MX14wK5Ox53ESplGZXndt3V
Gy48IbXdTTjbmHT07aqPVSkFgulkaE9Z3MTw+vyn/r10ww6R55XtoSJIbS/v4+Y0
mzjTYTSHmxzpGHR4Rs+E1q9/7y8tbxO0uzFMHlmD8fNNbkK3FlXymGfVJFjSJGSN
hTN97zEYUKco4M6RXAly8XUrOetSglZwul1+gQnHYYCx7Y8BhgpyZtyjVeKzg1Mw
wqgAi+1+cOLG2JjI+h0Xo0xqvuWwl3e2jrmBZNs9BWoXaaWA2L7oqPL3bxq2TeWs
kF56I7YH5eD5sUGvShjrJ9WfKeN4hWpYSif/qg58kqz/zbCSjmmfiqQ7HmjJUetm
JnAZaik38YhsDvR8K1gECQiN2myjojjdyg3ONBk2y0Yho+ClVSMPo/qCceRy21/q
LVTRThQ0tZExH8zEJrJt
=rx3Z
-----END PGP SIGNATURE-----
Merge tag 'qcom-drivers-for-4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux into next/drivers
Qualcomm ARM Based Driver Updates for v4.20
* Refactor of SCM compatibles and clock requirements
* SMEM cleanup
* Add LLCC EDAC driver
* Fixes for GENI clocks and macros
* Fix includes for llcc-slice and smem
* String overflow fixes for APR and wcnss_ctrl
* Fixup for COMPILE_TEST of qcom driver Kconfigs
* Cleanup of Kconfig depends of rpmh, smd_rpm, smsm, and smp2p
* Add SCM dependencies to SPM and rmtfs-mem
* tag 'qcom-drivers-for-4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux: (38 commits)
soc: qcom: geni: geni_se_clk_freq_match() should always accept multiples
soc: qcom: geni: Don't ignore clk_round_rate() errors in geni_se_clk_tbl_get()
soc: qcom: geni: Make version macros simpler
dt-bindings: firmware: scm: Add MSM8998 and SDM845
firmware: qcom: scm: Refactor clock handling
dt-bindings: firmware: scm: Refactor compatibles and clocks
soc: qcom: smem: a few last cleanups
soc: qcom: smem: verify partition host ids match
soc: qcom: smem: small change in global entry loop
soc: qcom: smem: verify partition offset_free_uncached
soc: qcom: smem: verify partition header size
soc: qcom: smem: introduce qcom_smem_partition_header()
soc: qcom: smem: require order of host ids to match
soc: qcom: smem: verify both host ids in partition header
soc: qcom: smem: small refactor in qcom_smem_enumerate_partitions()
soc: qcom: smem: always ignore partitions with 0 offset or size
soc: qcom: smem: initialize region struct only when successful
soc: qcom: smem: rename variable in qcom_smem_get_global()
drivers: qcom: rpmh-rsc: clear wait_for_compl after use
soc: qcom: rmtfs-mem: Validate that scm is available
...
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- Add support for enlisting the help of the EFI firmware to create memory
reservations that persist across kexec.
- Add page fault handling to the runtime services support code on x86 so
we can gracefully recover from buggy EFI firmware.
- Fix command line handling on x86 for the boot path that omits the stub's
PE/COFF entry point.
- Other assorted fixes.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEnNKg2mrY9zMBdeK7wjcgfpV0+n0FAlurXR8ACgkQwjcgfpV0
+n2CGwf/V4exixXjTDwkqE6gY5bq0Y3AL8tp89wdbJzjgGOIJLKh3CrGr8xEFHrv
oYObcvB3SfNEIyGeBjc/8ZMw1P/j98s6ucsMm0u+V52k7xxu/xJoIPw3bX2R8LLc
QhedUmKWLFQXxottaqzRFi1m0rP9TlAlc2n2pjIPCywjTPzeT/jBTtnRGRRdpDkN
uxwv59eXc6MXuwJGhM9lGIBCu8ra54SiSByJSKoMwNYXQRCLtiBUg5iibWkKigHp
9rQiimQnDOuPiZ6JGFx6pwSu7cqv3d8LYk5EnU3zYfzxAvHRfxuf40joSeZzySby
vZ4zRog79DxkSnuvaQ0+phQHiq+yQg==
=HZGk
-----END PGP SIGNATURE-----
Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/core
Pull EFI updates for v4.20 from Ard Biesheuvel:
- Add support for enlisting the help of the EFI firmware to create memory
reservations that persist across kexec.
- Add page fault handling to the runtime services support code on x86 so
we can gracefully recover from buggy EFI firmware.
- Fix command line handling on x86 for the boot path that omits the stub's
PE/COFF entry point.
- Other assorted fixes.
Move dcdbas to the more appropriate directory drivers/platform/x86.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Move dell_rbu to the more appropriate directory drivers/platform/x86.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The dell_rbu driver takes firmware update payloads and puts them in memory so
the system BIOS can find them after a reboot. This sometimes fails (though
rarely), because the memory containing the payload is in the CPU cache but
never gets written back to main memory before the system is rebooted (CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
- Adding firmware API for SoC with debugfs interface
Firmware driver communicates to Platform Management Unit (PMU) by using
SMC instructions routed to Arm Trusted Firmware (ATF). Initial version
adds support for base firmware driver with query and clock APIs.
EEMI spec is available here:
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEABECAAYFAlurMMcACgkQykllyylKDCGE6gCfY2tOaxQCcBUzmh5ZXSUiQdeM
BA8AoJgu8dBLcD/U9S5+lDlCEMY26eSh
=tgPT
-----END PGP SIGNATURE-----
Merge tag 'zynqmp-soc-for-v4.20-v2' of https://github.com/Xilinx/linux-xlnx into next/drivers
arm64: zynqmp: SoC changes for v4.20
- Adding firmware API for SoC with debugfs interface
Firmware driver communicates to Platform Management Unit (PMU) by using
SMC instructions routed to Arm Trusted Firmware (ATF). Initial version
adds support for base firmware driver with query and clock APIs.
EEMI spec is available here:
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
* tag 'zynqmp-soc-for-v4.20-v2' of https://github.com/Xilinx/linux-xlnx:
firmware: xilinx: Add debugfs for query data API
firmware: xilinx: Add debugfs interface
firmware: xilinx: Add clock APIs
firmware: xilinx: Add query data API
firmware: xilinx: Add Zynqmp firmware driver
dt-bindings: firmware: Add bindings for ZynqMP firmware
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Memory accesses performed by UEFI runtime services should be limited to:
- reading/executing from EFI_RUNTIME_SERVICES_CODE memory regions
- reading/writing from/to EFI_RUNTIME_SERVICES_DATA memory regions
- reading/writing by-ref arguments
- reading/writing from/to the stack.
Accesses outside these regions may cause the kernel to hang because the
memory region requested by the firmware isn't mapped in efi_pgd, which
causes a page fault in ring 0 and the kernel fails to handle it, leading
to die(). To save kernel from hanging, add an EFI specific page fault
handler which recovers from such faults by
1. If the efi runtime service is efi_reset_system(), reboot the machine
through BIOS.
2. If the efi runtime service is _not_ efi_reset_system(), then freeze
efi_rts_wq and schedule a new process.
The EFI page fault handler offers us two advantages:
1. Avoid potential hangs caused by buggy firmware.
2. Shout loud that the firmware is buggy and hence is not a kernel bug.
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Suggested-by: Matt Fleming <matt@codeblueprint.co.uk>
Based-on-code-from: Ricardo Neri <ricardo.neri@intel.com>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
[ardb: clarify commit log]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
After the kernel has booted, if any accesses by firmware causes a page
fault, the efi page fault handler would freeze efi_rts_wq and schedules
a new process. To do this, the efi page fault handler needs
efi_rts_work. Hence, make it accessible.
There will be no race conditions in accessing this structure, because
all the calls to efi runtime services are already serialized.
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Suggested-by: Matt Fleming <matt@codeblueprint.co.uk>
Based-on-code-from: Ricardo Neri <ricardo.neri@intel.com>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Add exporting the UEFI runtime service ResetSystem for upper application or test
tools to use.
Signed-off-by: Ivan Hu <ivan.hu@canonical.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
When building with CONFIG_EFI and CONFIG_EFI_STUB on ARM, the libstub
Makefile would use -mno-single-pic-base without checking it was
supported by the compiler. As the ARM (32-bit) clang backend does not
support this flag, the build would fail.
This changes the Makefile to check the compiler's support for
-mno-single-pic-base before using it, similar to c1c386681b ("ARM:
8767/1: add support for building ARM kernel with clang").
Signed-off-by: Alistair Strachan <astrachan@google.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Add kernel plumbing to reserve memory regions persistently on a EFI
system by adding entries to the MEMRESERVE linked list.
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Installing UEFI configuration tables can only be done before calling
ExitBootServices(), so if we want to use the new MEMRESRVE config table
from the kernel proper, we need to install a dummy entry from the stub.
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In order to allow the OS to reserve memory persistently across a
kexec, introduce a Linux-specific UEFI configuration table that
points to the head of a linked list in memory, allowing each kernel
to add list items describing memory regions that the next kernel
should treat as reserved.
This is useful, e.g., for GICv3 based ARM systems that cannot disable
DMA access to the LPI tables, forcing them to reuse the same memory
region again after a kexec reboot.
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Add debugfs file to query platform specific data from firmware
using debugfs interface.
Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
Signed-off-by: Jolly Shah <jollys@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Firmware-debug provides debugfs interface to all APIs.
Debugfs can be used to call firmware APIs with required
parameters.
Usage:
* Calling firmware API through debugfs:
# echo "<api-name> <arg1> .. <argn>" > /sys/.../zynqmp-firmware/pm
* Read output of last called firmware API:
# cat /sys/.../zynqmp-firmware/pm
Refer ug1200 for more information on these APIs:
* https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
Add basic debugfs file to get API version.
Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
Signed-off-by: Jolly Shah <jollys@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Add clock APIs to control clocks through firmware
interface.
Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
Signed-off-by: Jolly Shah <jollys@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Add ZynqMP firmware query data API to query platform
specific information(clocks, pins) from firmware.
Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
Signed-off-by: Jolly Shah <jollys@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.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: Rajan Vaja <rajanv@xilinx.com>
Signed-off-by: Jolly Shah <jollys@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
1. Addition of interface to fetch estimated power from the firmware
corresponding to each OPP of a device
2. Cleanup using strlcpy to ensure NULL-terminated strings for name
strings instead of relying on the firmware to do the same
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJboNR3AAoJEABBurwxfuKY3cwP/jpDt5dlO4mXgYbq/nSzCSUE
ll67qW9qAhJAxbf6k+eC6pZkbNNErUfsmeD30864S/1G80OqdsRHbOeAIS6NIKsW
LH6ZPnU9JGzsyLpT/QC1Tk84GzjqqGuBCFFbKqXIC5I5U4srvi+S6h/K+PE++cXe
wIB0HoGMzFdB6pGQfQOWCgNgSgk7poHoCuIlUP3S7lwUT0fSAWrC5zblxmG+VNo0
8jj+k4IbF+EqqsjYM/p8KUtCl7hvXtCRBaIdfCyhZBYxepVNbLjC5lNu41hou5Pn
Xzs6T8atELcJvjqcuHAr9PKa5MY7Ztb/9biaslaJn/WRBwHPPcVqgMw30pZIY2ZY
6Y81jnKm21jIR0tgTjHKQm3obny5utCwUqNrPkyE+HOZBvCfKHIFFZMEd3EZ0J0h
H8+xA9MFYWEUnShs8p63gaguwMK2ZPkacGgCVRPHmPCzZ3hv739Oz4JPMGQmPg9C
XpNu1budX1CplHTjbTTo9xhN7VcubLoJdLta2JiMQKOy1+XiDpp4aqqfydO2Cbbk
nBwyWza3qDhxd289tYTQPn+FCCHQXq/T+cbfBMQkTx9MQE0Z4cl9DI29/jxPScMY
m0MIxeSdgIKtUi0t4ybV90VuUdQw9GcPiJpAtgPf/SM0/MpXJjE9GkzqsKETDNZ2
0iscZDH1DQle+OMyo54f
=ux6I
-----END PGP SIGNATURE-----
Merge tag 'scmi-updates-4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into next/drivers
SCMI updates for v4.20
1. Addition of interface to fetch estimated power from the firmware
corresponding to each OPP of a device
2. Cleanup using strlcpy to ensure NULL-terminated strings for name
strings instead of relying on the firmware to do the same
* tag 'scmi-updates-4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: add a getter for power of performance states
firmware: arm_scmi: use strlcpy to ensure NULL-terminated strings
Signed-off-by: Olof Johansson <olof@lixom.net>
Trivial fix to spelling mistake in comment
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This function checks the header for sanity, registers a bus, and
populates devices for each coreboot table entry. Let's just populate
devices here and pull the other bits up into the caller so that this
function can be repurposed for pure device creation and registration.
Cc: Wei-Ning Huang <wnhuang@chromium.org>
Cc: Julius Werner <jwerner@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>
Cc: Samuel Holland <samuel@sholland.org>
Suggested-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is all system memory, so we shouldn't be mapping this all with
ioremap() as these aren't I/O regions. Instead, they're memory regions
so we should use memremap(). Pick MEMREMAP_WB so we can map memory from
RAM directly if that's possible, otherwise it falls back to
ioremap_cache() like is being done here already. This also nicely
silences the sparse warnings in this code and reduces the need to copy
anything around anymore.
Cc: Wei-Ning Huang <wnhuang@chromium.org>
Cc: Julius Werner <jwerner@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>
Cc: Samuel Holland <samuel@sholland.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The DT based and ACPI based platform drivers here do the same thing; map
some memory and hand it over to the coreboot bus to populate devices.
The only major difference is that the DT based driver doesn't map the
coreboot table header to figure out how large of a region to map for the
whole coreboot table and it uses of_iomap() instead of ioremap_cache().
A cached or non-cached mapping shouldn't matter here and mapping some
smaller region first before mapping the whole table is just more work
but should be OK. In the end, we can remove two files and combine the
code all in one place making it easier to reason about things.
We leave the old Kconfigs in place for a little while longer but make
them hidden and select the previously hidden config option. This way
users can upgrade without having to know to reselect this config in the
future. Later on we can remove the old hidden configs.
Cc: Wei-Ning Huang <wnhuang@chromium.org>
Cc: Julius Werner <jwerner@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>
Cc: Samuel Holland <samuel@sholland.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The bus is registered in module_init() but is unregistered when the
platform driver remove() function calls coreboot_table_exit(). That
isn't symmetric and it causes the bus to appear on systems that compile
this code in, even when there isn't any coreboot firmware on the device.
Let's move the registration to the coreboot_table_init() function so
that it matches the exit path.
Cc: Wei-Ning Huang <wnhuang@chromium.org>
Cc: Julius Werner <jwerner@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>
Cc: Samuel Holland <samuel@sholland.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Both callers of coreboot_table_init() ioremap the pointer that comes in
but they don't unmap the memory on failure. Both of them also fail probe
immediately with the return value of coreboot_table_init(), leaking a
mapping when it fails. The mapping isn't necessary at all after devices
are populated either, so we can just drop the mapping here when we exit
the function. Let's do that to simplify the code a bit and plug the leak.
Cc: Wei-Ning Huang <wnhuang@chromium.org>
Cc: Julius Werner <jwerner@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>
Cc: Samuel Holland <samuel@sholland.org>
Fixes: 570d30c282 ("firmware: coreboot: Expose the coreboot table as a bus")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that the /firmware/coreboot node in DT is populated by the core DT
platform code with commit 3aa0582fdb ("of: platform: populate
/firmware/ node from of_platform_default_populate_init()") we should and
can remove the platform device creation here. Otherwise, the
of_platform_device_create() call will fail, the coreboot of driver won't
be registered, and this driver will never bind. At the same time, we
should move this driver to use MODULE_DEVICE_TABLE so that module
auto-load works properly when the coreboot device is auto-populated and
we should drop the of_node handling that was presumably placed here to
hold a reference to the DT node created during module init that no
longer happens.
Cc: Wei-Ning Huang <wnhuang@chromium.org>
Cc: Julius Werner <jwerner@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Cc: Samuel Holland <samuel@sholland.org>
Reviewed-by: Sudeep Holla <Sudeep.Holla@arm.com>
Fixes: 3aa0582fdb ("of: platform: populate /firmware/ node from of_platform_default_populate_init()")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The structure gsmi_dev is local to the source and does not need to be
in global scope, so make it static.
Cleans up sparse warning:
symbol 'gsmi_dev' was not declared. Should it be static?
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
At one point in time all "future" platforms required three clocks, so
the binding and driver was written to treat this as the default case.
But new platforms has no clock requirements, which currently makes them
all a special case, causing the need for a patch in the binding and
driver for each new platform added.
This patch reworks the driver logic so that it will attempt to acquire
all three clocks and fail based on the given compatible. This allow us
to drop the clock requirement from "qcom,scm", in a way that will remain
backwards compatible with existing DT files.
Specific compatibles are added for apq8084, msm8916 and msm8974 to match
the updated binding and although equivalent to qcom,scm both ipq4019 and
msm8996 are kept as these have been used without fallback to qcom,scm.
The result of this patch is that new platforms, that require no clocks,
can be use the fallback compatible of "qcom,scm".
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
The Amlogic Meson SoC Secure Monitor implements a call to retrieve an unique
SoC ID starting from the GX Family and all new families.
The serial number is simply exposed as a sysfs entry under the firmware
sysfs directory.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Default EFI_ARMSTUB_DTB_LOADER to y to allow the dtb= command
line parameter to function with efi loader.
Required for development purposes and to boot on existing bootloaders
that do not support devicetree provided by the firmware or by the
bootloader.
Fixes: 3d7ee348aa ("efi/libstub/arm: Add opt-in Kconfig option ...")
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The SCMI protocol can be used to get power estimates from firmware
corresponding to each performance state of a device. Although these power
costs are already managed by the SCMI firmware driver, they are not
exposed to any external subsystem yet.
Fix this by adding a new get_power() interface to the exisiting perf_ops
defined for the SCMI protocol.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Replace all the memcpy() for copying name strings from the firmware with
strlcpy() to make sure we are bounded by the source buffer size and we
also always have NULL-terminated strings.
This is needed to avoid out of bounds accesses if the firmware returns
a non-terminated string.
Reported-by: Olof Johansson <olof@lixom.net>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Firmware can provide zero as values for sustained performance level and
corresponding sustained frequency in kHz in order to hide the actual
frequencies and provide only abstract values. It may endup with divide
by zero scenario resulting in kernel panic.
Let's set the multiplication factor to one if either one or both of them
(sustained_perf_level and sustained_freq) are set to zero.
Fixes: a9e3fbfaa0 ("firmware: arm_scmi: add initial support for performance protocol")
Reported-by: Ionela Voinescu <ionela.voinescu@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Texas Instrument's System Control Interface (TISCI) permits the
ability for Operating Systems to running in virtual machines to be
able to independently communicate with the firmware without the need
going through an hypervisor.
The "host-id" in effect is the hardware representation of the
host (example: VMs locked to a core) as identified to the System
Controller.
Provide support as an optional parameter implementation and use the
compatible data as default if one is not provided by device tree.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
