Introduce a new SMC command INTEL_SIP_SMC_FUNCID_SERVICE_COMPLETED
that polls if a previous asynchronous command was completed. This
SMC command is used by the new FPGA Crypto Service (FCS).
A basic example is that the FCS sends an AES data encryption
call to the secure device manager(SDM) and waits for the completion
of the operation by continuously polling the results with the new
command.
Signed-off-by: Ang Tien Sung <tien.sung.ang@intel.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Link: https://lore.kernel.org/r/20220711223140.2307945-2-dinguyen@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Extend Intel service layer driver to support FPGA Crypto service(FCS)
features on Intel Soc platforms. Adding an additional channel and FCS
platform driver ("intel_fcs") as part of the probe method.
FCS driver uses the driver to send crypto operations' commands to
the secure device manager(SDM) on Intel Soc platforms Stratix10 and
Agilex.
Signed-off-by: Ang Tien Sung <tien.sung.ang@intel.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Link: https://lore.kernel.org/r/20220711223140.2307945-1-dinguyen@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qualcomm driver updates for v5.20
This introduces a new driver that requests interconnect bandwidth based
on throughput measurements of the bwmon hardware blocks found associated
with, among other things, the CPU subsystem on many Qualcomm platforms.
It introduces support for the SCM wrapper driver to vote for
interconnect bandwidth for operations that needs bandwidth to the crypto
engine. This ensures both performance and guards against issues caused
by lacking votes for this path.
The socinfo driver gains knowledge about the SC7180P SoC.
It contains a range of fixes for spelling mistakes, refcount leaks in
various drivers and removes some redundant code from the apr remove
path.
The SCM DT bindings are updated to declare support for QCS404, SM6125
and SDX65.
The command db driver has a strncpy() converted to strscpy_pad() and
then back again with proper documentation to why this was the right API.
* tag 'qcom-drivers-for-5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
soc: qcom: icc-bwmon: Add bandwidth monitoring driver
dt-bindings: interconnect: qcom,msm8998-cpu-bwmon: add BWMON device
soc/qcom: Make QCOM_RPMPD select PM_GENERIC_DOMAINS/_OF
soc: qcom: aoss: Fix refcount leak in qmp_cooling_devices_register
soc: qcom: llcc: Fix syntax errors in comments
soc: qcom: ocmem: Fix refcount leak in of_get_ocmem
dt-bindings: soc: qcom,wcnss: remove unneeded ref for names
firmware: qcom_scm: Add bw voting support to the SCM interface
dt-bindings: firmware: qcom-scm: Add interconnects property
soc: qcom: cmd-db: replace strscpy_pad() with strncpy()
dt-bindings: firmware: scm: Add compatible for SDX65
dt-bindings: arm: qcom: switch maintainer to Bjorn
soc: qcom: rpmhpd: fix typos in comment
soc: qcom: correct kerneldoc
soc: qcom: cmd-db: replace strncpy() with strscpy_pad()
firmware: qcom_scm-legacy: correct kerneldoc
dt-bindings: firmware: document Qualcomm QCS404 and SM6125 SCM
soc: qcom: apr: Drop redundant check in .remove()
firmware: qcom_scm: drop unexpected word "the"
soc: qcom: socinfo: Add an ID for sc7180P
Link: https://lore.kernel.org/r/20220712021830.1271398-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
firmware: tegra: Changes for v5.20-rc1
Contains a fix that avoids unaligned accesses to IPC memory, which in
turn helps in suppressing speculative reads from out-of-bounds memory.
Another patch performs some minor cleanup around debugfs API usage.
* tag 'tegra-for-5.20-firmware' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
firmware: tegra: Fix error check return value of debugfs_create_file()
firmware: tegra: bpmp: Do only aligned access to IPC memory area
Link: https://lore.kernel.org/r/20220708185608.676474-3-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Commit 98f30d0ecf ("ACPI: power: Switch to sys-off handler API")
switched the ACPI sleep code from directly setting the old global
pm_power_off handler to using the new register_sys_off_handler()
mechanism with a priority of SYS_OFF_PRIO_FIRMWARE.
This is a problem when the old global pm_power_off handler would later
be overwritten, such as done by the late_initcall(efi_shutdown_init):
if (efi_poweroff_required())
pm_power_off = efi_power_off;
The old global pm_power_off handler gets run with a priority of
SYS_OFF_PRIO_DEFAULT which is lower then SYS_OFF_PRIO_FIRMWARE, causing
acpi_power_off() to run first, changing the behavior from before
the ACPI sleep code switched to the new register_sys_off_handler().
Switch the registering of efi_power_off over to register_sys_off_handler()
with a priority of SYS_OFF_PRIO_FIRMWARE + 1 so that it will run before
acpi_power_off() as before.
Note since the new sys-off-handler code will try all handlers in
priority order, there is no more need for the EFI code to store and
call the original pm_power_off handler.
Fixes: 98f30d0ecf ("ACPI: power: Switch to sys-off handler API")
Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20220708131412.81078-3-hdegoede@redhat.com
If an error occurs, debugfs_create_file() will return ERR_PTR(-ERROR),
so use IS_ERR() to check it.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Lv Ruyi <lv.ruyi@zte.com.cn>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Arm SCMI updates for v5.20
The main additions this time around are:
1. The capability to trace full SCMI message headers and payloads.
The recent unearthing of chain of old firmware issues motivated
this effort so that it is easier to trace them and debug quicker
than it took this time around in absence of such tracing.
2. SCMI System power control driver to handle platform's requests for a
graceful shutdown. Though the system power control protocol has been
around since the begining of SCMI, it lacked the timeout information
that was added in SCMI v3.1 that enables kernel to take appropriate
action within the timeout and doesn't have to rely on any other
user inputs(which was blocking factor for addition of this driver
earlier)
3. Support for SCMI Power Capping protocol that was introduced in SCMI v3.1
This protocol is intended for controlling and monitoring the power
consumption of power capping domains. The firmware also provides the
hierarchy of powercap domains by providing parent domain information.
It also contains a bug fix in the old SCPI driver addressing possible
user-after-free issues.
* tag 'scmi-updates-5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Use fast channel tracing
include: trace: Add SCMI fast channel tracing
firmware: arm_scmi: Add SCMI v3.1 powercap fast channels support
firmware: arm_scmi: Generalize the fast channel support
firmware: arm_scmi: Add SCMI v3.1 powercap protocol basic support
dt-bindings: firmware: arm,scmi: Add support for powercap protocol
firmware: arm_scmi: Add SCMI System Power Control driver
firmware: arm_scmi: Add devm_protocol_acquire helper
firmware: arm_scmi: Add SCMI v3.1 System Power extensions
firmware: arm_scmi: Support only one single system power device
firmware: arm_scmi: Use new SCMI full message tracing
include: trace: Add SCMI full message tracing
firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails
firmware: arm_scmi: Remove usage of the deprecated ida_simple_xxx API
firmware: arm_scmi: Fix response size warning for OPTEE transport
firmware: arm_scmi: Relax CLOCK_DESCRIBE_RATES out-of-spec checks
Link: https://lore.kernel.org/r/20220706115045.2272678-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Pull ARM SoC fixes from Arnd Bergmann:
"Another set of minor patches for Arm DTS files and soc specific
drivers:
- More reference counting bug fixes for DT nodes, and other trivial
code fixes
- Multiple code fixes for the Arm SCMI firmware driver to improve
compatibility with firmware implementations.
- A patch series for at91 to address power management issues from
using the wrong DT compatible properties.
- A series of patches to fix pad settings for NXP imx8mp to leave the
configuration untouched from the boot loader
- Additional DT fixes for qualcomm and NXP platforms
- A boot time fix for stm32mp15 DT
- Konrad Dybcio becomes an additional reviewer for the Qualcomm
platforms"
* tag 'soc-fixes-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (42 commits)
soc: qcom: smem: use correct format characters
ARM: dts: stm32: add missing usbh clock and fix clk order on stm32mp15
ARM: dts: stm32: delete fixed clock node on STM32MP15-SCMI
ARM: dts: stm32: DSI should use LSE SCMI clock on DK1/ED1 STM32 board
ARM: dts: stm32: use the correct clock source for CEC on stm32mp151
ARM: dts: stm32: fix pwr regulators references to use scmi
soc: ixp4xx/npe: Fix unused match warning
ARM: at91: pm: Mark at91_pm_secure_init as __init
ARM: at91: fix soc detection for SAM9X60 SiPs
ARM: dts: at91: sama5d2_icp: fix eeprom compatibles
ARM: dts: at91: sam9x60ek: fix eeprom compatible and size
ARM: at91: pm: use proper compatibles for sama7g5's rtc and rtt
ARM: at91: pm: use proper compatibles for sam9x60's rtc and rtt
ARM: at91: pm: use proper compatible for sama5d2's rtc
arm64: dts: qcom: msm8992-*: Fix vdd_lvs1_2-supply typo
firmware: arm_scmi: Remove usage of the deprecated ida_simple_xxx API
firmware: arm_scmi: Fix response size warning for OPTEE transport
arm64: dts: imx8mp-icore-mx8mp-edim2.2: correct pad settings
arm64: dts: imx8mp-phyboard-pollux-rdk: correct i2c2 & mmc settings
arm64: dts: imx8mp-phyboard-pollux-rdk: correct eqos pad settings
...
Add an SCMI System Power control driver to handle platform's requests
carried by SYSTEM_POWER_STATE_NOTIFIER notifications: such platform
requested system-wide power state transitions are handled accordingly,
gracefully or forcefully, depending on the notifications' message flags.
Graceful requests are relayed to userspace using the same Kernel API used
to handle ACPI Shutdown bus events.
Link: https://lore.kernel.org/r/20220704101933.2981635-5-cristian.marussi@arm.com
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add a method to get hold of a protocol, causing it to be initialized and
its resource accounting updated, without getting access to its operations
and handle.
Some protocols, like SCMI SystemPower, do not expose any protocol ops to
the kernel OSPM agent but still need to be at least initialized. This
helper avoids the need to invoke a full devm_get_protocol() only to get
the protocol initialized while throwing away unused the protocol ops and
handle.
Link: https://lore.kernel.org/r/20220704101933.2981635-4-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
In order to minimize SCMI platform fw-side complexity, only one single SCMI
platform should be in charge of SCMI SystemPower protocol communications
with the OSPM. Enforce the existence of one single unique device associated
with SystemPower protocol across any possible number of SCMI platforms, and
warn if a system tries to register different SystemPower devices from
multiple platforms.
Link: https://lore.kernel.org/r/20220704101933.2981635-2-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Arm SCMI firmware driver fixes for v5.19
Few more fixes to address:
1. Issue reported on Juno with HDLCD clock which turned out to be yet
another firmware issue. The firmware is not conformant to the spec and
we now have to workaround as this may be copied to other platforms as
well. The spec expects to return size of 3 for a range clock rate
description while the firmware returns 1. We have other ways to validate
all the 3 entries the driver reads are polpulated and we use the same
to workaround this firmware bug.
2. Optee transport not setting the correct reponse length which is similar
to the one reported earlier on Rockchip platform.
3. Drop the usage of the deprecated ida_simple_{get,remove} and migrate to the
ida_{alloc,free}
* tag 'scmi-fixes-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Remove usage of the deprecated ida_simple_xxx API
firmware: arm_scmi: Fix response size warning for OPTEE transport
firmware: arm_scmi: Relax CLOCK_DESCRIBE_RATES out-of-spec checks
Link: https://lore.kernel.org/r/20220628133315.699803-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
SGI interrupt register and reset is performed by EEMI ioctl
IOCTL_REGISTER_SGI. However, this is not correct use of EEMI call.
SGI registration functionality does not qualify as energy management
activity and so shouldn't be mapped to EEMI call.
This new call will replace IOCTL_REGISTER_SGI and will be handled by TF-A
specific handler in TF-A. To maintain backward compatibility for a while
firmware driver will still use IOCTL_REGISTER_SGI as fallback strategy if
new call fails or is not supported by TF-A.
This new design also helps to make TF-A as pass through layer for EEMI
calls. So we don't have to maintain PM_IOCTL as EEMI API ID in TF-A.
Signed-off-by: Tanmay Shah <tanmay.shah@xilinx.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20220607224253.54919-1-tanmay.shah@xilinx.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
This patch fixes the spelling error in firmware/efi/memmap.c, changing
it to the correct word.
Signed-off-by: Zheng Zhi Yuan <kevinjone25@g.ncu.edu.tw>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Some protocols check the response size with the expected value but optee
shared memory doesn't return such size whereas it is available in the
optee output buffer.
As an example, the base protocol compares the response size with the
expected result when requesting the list of protocol which triggers a
warning with optee shared memory:
arm-scmi firmware:scmi0: Malformed reply - real_sz:116 calc_sz:4 (loop_num_ret:4)
Save the output buffer length and use it when fetching the answer.
Link: https://lore.kernel.org/r/20220624074549.3298-1-vincent.guittot@linaro.org
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Pull ARM SoC fixes from Arnd Bergmann:
"A number of fixes have accumulated, but they are largely for harmless
issues:
- Several OF node leak fixes
- A fix to the Exynos7885 UART clock description
- DTS fixes to prevent boot failures on TI AM64 and J721s2
- Bus probe error handling fixes for Baikal-T1
- A fixup to the way STM32 SoCs use separate dts files for different
firmware stacks
- Multiple code fixes for Arm SCMI firmware, all dealing with
robustness of the implementation
- Multiple NXP i.MX devicetree fixes, addressing incorrect data in DT
nodes
- Three updates to the MAINTAINERS file, including Florian Fainelli
taking over BCM283x/BCM2711 (Raspberry Pi) from Nicolas Saenz
Julienne"
* tag 'soc-fixes-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (29 commits)
ARM: dts: aspeed: nuvia: rename vendor nuvia to qcom
arm: mach-spear: Add missing of_node_put() in time.c
ARM: cns3xxx: Fix refcount leak in cns3xxx_init
MAINTAINERS: Update email address
arm64: dts: ti: k3-am64-main: Remove support for HS400 speed mode
arm64: dts: ti: k3-j721s2: Fix overlapping GICD memory region
ARM: dts: bcm2711-rpi-400: Fix GPIO line names
bus: bt1-axi: Don't print error on -EPROBE_DEFER
bus: bt1-apb: Don't print error on -EPROBE_DEFER
ARM: Fix refcount leak in axxia_boot_secondary
ARM: dts: stm32: move SCMI related nodes in a dedicated file for stm32mp15
soc: imx: imx8m-blk-ctrl: fix display clock for LCDIF2 power domain
ARM: dts: imx6qdl-colibri: Fix capacitive touch reset polarity
ARM: dts: imx6qdl: correct PU regulator ramp delay
firmware: arm_scmi: Fix incorrect error propagation in scmi_voltage_descriptors_get
firmware: arm_scmi: Avoid using extended string-buffers sizes if not necessary
firmware: arm_scmi: Fix SENSOR_AXIS_NAME_GET behaviour when unsupported
ARM: dts: imx7: Move hsic_phy power domain to HSIC PHY node
soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in brcmstb_pm_probe
MAINTAINERS: Update BCM2711/BCM2835 maintainer
...
Move the fiddly bits of the efivar layer into its only remaining user,
efivarfs, and confine its use to that particular module. All other uses
of the EFI variable store have no need for this additional layer of
complexity, given that they either only read variables, or read and
write variables into a separate GUIDed namespace, and cannot be used to
manipulate EFI variables that are covered by the EFI spec and/or affect
the boot flow.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
__efivar_entry_iter() uses a list iterator in a dubious way, i.e., it
assumes that the iteration variable always points to an object of the
appropriate type, even if the list traversal exhausts the list
completely, in which case it will point somewhere in the vicinity of the
list's anchor instead.
Fortunately, we no longer use this function so we can just get rid of it
entirely.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Switch the caching linked-list efivars layer implementation to the newly
introduced efivar get/set variable wrappers, instead of accessing the
lock and the ops pointer directly. This will permit us to move this code
out of the public efivars API, and into efivarfs once the obsolete sysfs
access method is finally removed.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Both efivars and efivarfs uses __efivar_entry_iter() to go over the
linked list that shadows the list of EFI variables held by the firmware,
but fail to call the begin/end helpers that are documented as a
prerequisite.
So switch to the proper version, which is efivar_entry_iter(). Given
that in both cases, efivar_entry_remove() is invoked with the lock held
already, don't take the lock there anymore.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Commit 5d9db88376 ("efi: Add support for a UEFI variable filesystem")
dated Oct 5, 2012, introduced a new efivarfs pseudo-filesystem to
replace the efivars sysfs interface that was used up to that point to
expose EFI variables to user space.
The main problem with the sysfs interface was that it only supported up
to 1024 bytes of payload per file, whereas the underlying variables
themselves are only bounded by a platform specific per-variable and
global limit that is typically much higher than 1024 bytes.
The deprecated sysfs interface is only enabled on x86 and Itanium, other
EFI enabled architectures only support the efivarfs pseudo-filesystem.
So let's finally rip off the band aid, and drop the old interface
entirely. This will make it easier to refactor and clean up the
underlying infrastructure that is shared between efivars, efivarfs and
efi-pstore, and is long overdue for a makeover.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Avoid the efivars layer and simply call the newly introduced EFI
varstore helpers instead. This simplifies the code substantially, and
also allows us to remove some hacks in the shared efivars layer that
were added for efi-pstore specifically.
In order to be able to delete the EFI variable associated with a record,
store the UTF-16 name of the variable in the pstore record's priv field.
That way, we don't have to make guesses regarding which variable the
record may have been loaded from.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The current efivars layer is a jumble of list iterators, shadow data
structures and safe variable manipulation helpers that really belong in
the efivarfs pseudo file system once the obsolete sysfs access method to
EFI variables is removed.
So split off a minimal efivar get/set variable API that reuses the
existing efivars_lock semaphore to mediate access to the various runtime
services, primarily to ensure that performing a SetVariable() on one CPU
while another is calling GetNextVariable() in a loop to enumerate the
contents of the EFI variable store does not result in surprises.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Even though the efivars_lock lock is documented as protecting the
efivars->ops pointer (among other things), efivar_init() happily
releases and reacquires the lock for every EFI variable that it
enumerates. This used to be needed because the lock was originally a
spinlock, which prevented the callback that is invoked for every
variable from being able to sleep. However, releasing the lock could
potentially invalidate the ops pointer, but more importantly, it might
allow a SetVariable() runtime service call to take place concurrently,
and the UEFI spec does not define how this affects an enumeration that
is running in parallel using the GetNextVariable() runtime service,
which is what efivar_init() uses.
In the meantime, the lock has been converted into a semaphore, and the
only reason we need to drop the lock is because the efivarfs pseudo
filesystem driver will otherwise deadlock when it invokes the efivars
API from the callback to create the efivar_entry items and insert them
into the linked list. (EFI pstore is affected in a similar way)
So let's switch to helpers that can be used while the lock is already
taken. This way, we can hold on to the lock throughout the enumeration.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Use memcpy_toio and memcpy_fromio variants of memcpy to guarantee no
unaligned access to IPC memory area. This is to allow the IPC memory to
be mapped as Device memory to further suppress speculative reads from
happening within the 64 kB memory area above the IPC memory when 64 kB
memory pages are used.
Signed-off-by: Timo Alho <talho@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Nothing defined in the header is used by drivers/firmware/efi/sysfb_efi.c
but also, including it can lead to build errors when built on arches that
don't have an asm/efi.h header file.
This can happen for example if a driver that is built when COMPILE_TEST is
enabled selects the SYSFB symbol, e.g. on powerpc with allyesconfig:
drivers/firmware/efi/sysfb_efi.c:29:10: fatal error: asm/efi.h: No such file or directory
29 | #include <asm/efi.h>
| ^~~~~~~~~~~
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Avoid abusing the efivar API by passing locally instantiated
efivar_entry structs into efivar_set_entry_safe(), rather than using the
API as intended. Instead, just call efi.set_variable() directly.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The efivars intermediate variable access layer provides an abstraction
that permits the EFI variable store to be replaced by something else
that implements a compatible interface, and caches all variables in the
variable store for fast access via the efivarfs pseudo-filesystem.
The SSDT override feature does not take advantage of either feature, as
it is only used when the generic EFI implementation of efivars is used,
and it traverses all variables only once to find the ones it is
interested in, and frees all data structures that the efivars layer
keeps right after.
So in this case, let's just call EFI's code directly, using the function
pointers in struct efi.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
A reply to CLOCK_DESCRIBE_RATES issued against a non rate-discrete clock
should be composed of a triplet of rates descriptors (min/max/step)
returned all in one reply message.
This is not always the case when dealing with some SCMI server deployed in
the wild: relax such constraint while maintaining memory safety by checking
carefully the returned payload size.
While at that cleanup a stale debug printout.
Link: https://lore.kernel.org/r/20220616170347.2800771-1-cristian.marussi@arm.com
Fixes: 7bc7caafe6 ("firmware: arm_scmi: Use common iterators in the clock protocol")
Tested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Commit b05b9f5f9d ("x86, mirror: x86 enabling - find mirrored memory
ranges") introduce the efi_find_mirror() function on x86. In order to reuse
the API we make it public.
Arm64 can support mirrored memory too, so function efi_find_mirror() is added to
efi_init() to this support for arm64.
Since efi_init() is shared by ARM, arm64 and riscv, this patch will bring
mirror memory support for these architectures, but this support is only tested
in arm64.
Signed-off-by: Ma Wupeng <mawupeng1@huawei.com>
Link: https://lore.kernel.org/r/20220614092156.1972846-2-mawupeng1@huawei.com
[ardb: fix subject to better reflect the payload]
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
scmi_voltage_descriptors_get() will incorrecly return an error code if
the last iteration of the for loop that retrieves the descriptors is
skipped due to an error. Skipping an iteration in the loop is not an
error, but the `ret` value from the last iteration will be propagated
when the function returns.
Fix by not saving return values that should not be propagated. This
solution also minimizes the risk of future patches accidentally
re-introducing this bug.
Link: https://lore.kernel.org/r/20220610140055.31491-1-ludvig.parsson@axis.com
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Ludvig Pärsson <ludvig.parsson@axis.com>
[sudeep.holla: Removed unneeded reset_rx_to_maxsz and check for return
value from scmi_voltage_levels_get as suggested by Cristian]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Commit b260fccaeb ("firmware: arm_scmi: Add SCMI v3.1 protocol extended
names support") moved all the name string buffers to use the extended buffer
size of 64 instead of the required 16 bytes. While that should be fine if
the firmware terminates the string before 16 bytes, there is possibility
of copying random data if the name is not NULL terminated by the firmware.
SCMI base protocol agent_name/vendor_id/sub_vendor_id are defined by the
specification as NULL-terminated ASCII strings up to 16-bytes in length.
The underlying buffers and message descriptors are currently bigger than
needed; resize them to fit only the strictly needed 16 bytes to avoid
any possible leaks when reading data from the firmware.
Change the size argument of strlcpy to use SCMI_SHORT_NAME_MAX_SIZE always
when dealing with short domain names, so as to limit the possibility that
an ill-formed non-NULL terminated short reply from the SCMI platform
firmware can leak stale content laying in the underlying transport shared
memory area.
While at that, convert all strings handling routines to use the preferred
strscpy.
Link: https://lore.kernel.org/r/20220608095530.497879-1-cristian.marussi@arm.com
Fixes: b260fccaeb ("firmware: arm_scmi: Add SCMI v3.1 protocol extended names support")
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
