Add write fuse api for i.MX93/i.MX95
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Sebastien Haezebrouck <sebastien.haezebrouck@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
[ Upstream commit df7ecce842 ]
Clearing BSS should only be done once, at the very beginning.
efi_pe_entry() is the entrypoint from the firmware, which may not clear
BSS and so it is done explicitly. However, efi_pe_entry() is also used
as an entrypoint by the mixed mode startup code, in which case BSS will
already have been cleared, and doing it again at this point will corrupt
global variables holding the firmware's GDT/IDT and segment selectors.
So make the memset() conditional on whether the EFI stub is running in
native mode.
Fixes: b3810c5a2c ("x86/efistub: Clear decompressor BSS in native EFI entrypoint")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b3810c5a2c ]
The EFI stub on x86 no longer invokes the decompressor as a subsequent
boot stage, but calls into the decompression code directly while running
in the context of the EFI boot services.
This means that when using the native EFI entrypoint (as opposed to the
EFI handover protocol, which clears BSS explicitly), the firmware PE
image loader is being relied upon to ensure that BSS is zeroed before
the EFI stub is entered from the firmware.
As Radek's report proves, this is a bad idea. Not all loaders do this
correctly, which means some global variables that should be statically
initialized to 0x0 may have junk in them.
So clear BSS explicitly when entering via efi_pe_entry(). Note that
zeroing BSS from C code is not generally safe, but in this case, the
following assignment and dereference of a global pointer variable
ensures that the memset() cannot be deferred or reordered.
Cc: <stable@kernel.org> # v6.1+
Reported-by: Radek Podgorny <radek@podgorny.cz>
Closes: https://lore.kernel.org/all/a99a831a-8ad5-4cb0-bff9-be637311f771@podgorny.cz
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit fccfa646ef ]
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures
is not enough for a 64-bit phys_addr_t:
drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open':
drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size]
295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL);
| ^
Use the correct type instead here.
Fixes: f24c4d4780 ("efi/capsule-loader: Reinstate virtual capsule mapping")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0bcff59ef7 ]
Adding memblocks for soft-reserved regions prevents them from later being
hotplugged in by dax_kmem.
Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit de1034b38a ]
md_size will have been narrowed if we have >= 4GB worth of pages in a
soft-reserved region.
Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit afb2a4fb84 upstream.
The cflags for the RISC-V efistub were missing -mno-relax, thus were
under the risk that the compiler could use GP-relative addressing. That
happened for _edata with binutils-2.41 and kernel 6.1, causing the
relocation to fail due to an invalid kernel_size in handle_kernel_image.
It was not yet observed with newer versions, but that may just be luck.
Cc: <stable@vger.kernel.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
blocking reseed flag which is BIT(1) of Flags field is not setting,
so added ele_rng_msg structure as per firmware rng command api strcuture.
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
commit 7e50262229 upstream.
The native EFI entrypoint does not take a struct boot_params from the
loader, but instead, it constructs one from scratch, using the setup
header data placed at the start of the image.
This setup header is placed in a way that permits legacy loaders to
manipulate the contents (i.e., to pass the kernel command line or the
address and size of an initial ramdisk), but EFI boot does not use it in
that way - it only copies the contents that were placed there at build
time, but EFI loaders will not (and should not) manipulate the setup
header to configure the boot. (Commit 63bf28ceb3 "efi: x86: Wipe
setup_data on pure EFI boot" deals with some of the fallout of using
setup_data in a way that breaks EFI boot.)
Given that none of the non-zero values that are copied from the setup
header into the EFI stub's struct boot_params are relevant to the boot
now that the EFI stub no longer enters via the legacy decompressor, the
copy can be omitted altogether.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20230912090051.4014114-19-ardb@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5f51c5d0e9 upstream.
Now that the EFI stub always zero inits its BSS section upon entry,
there is no longer a need to place the BSS symbols carried by the stub
into the .data section.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20230912090051.4014114-18-ardb@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 2f77465b05 ]
The EFI stub's kernel placement logic randomizes the physical placement
of the kernel by taking all available memory into account, and picking a
region at random, based on a random seed.
When KASLR is disabled, this seed is set to 0x0, and this results in the
lowest available region of memory to be selected for loading the kernel,
even if this is below LOAD_PHYSICAL_ADDR. Some of this memory is
typically reserved for the GFP_DMA region, to accommodate masters that
can only access the first 16 MiB of system memory.
Even if such devices are rare these days, we may still end up with a
warning in the kernel log, as reported by Tom:
swapper/0: page allocation failure: order:10, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
Fix this by tweaking the random allocation logic to accept a low bound
on the placement, and set it to LOAD_PHYSICAL_ADDR.
Fixes: a1b87d54f4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot")
Reported-by: Tom Englund <tomenglund26@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218404
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a7a6a01f88 ]
The recently introduced EFI memory attributes protocol should be used
if it exists to ensure that the memory allocation created for the kernel
permits execution. This is needed for compatibility with tightened
requirements related to Windows logo certification for x86 PCs.
Currently, we simply strip the execute protect (XP) attribute from the
entire range, but this might be rejected under some firmware security
policies, and so in a subsequent patch, this will be changed to only
strip XP from the executable region that runs early, and make it
read-only (RO) as well.
In order to catch any issues early, ensure that the memory attribute
protocol works as intended, and give up if it produces spurious errors.
Note that the DXE services based fallback was always based on best
effort, so don't propagate any errors returned by that API.
Fixes: a1b87d54f4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Add mu_buf_offset variable to keep track of offset of
MU buffer been returned to user.
Issue:
On every ioctl call to get_mu_buffer, linux returns the base
offset of MU.
Fix:
Add mu_buf_offset to save last shared offset value.
Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
commit 437a310b22 upstream.
On reception of a completion interrupt the shared memory area is accessed
to retrieve the message header at first and then, if the message sequence
number identifies a transaction which is still pending, the related
payload is fetched too.
When an SCMI command times out the channel ownership remains with the
platform until eventually a late reply is received and, as a consequence,
any further transmission attempt remains pending, waiting for the channel
to be relinquished by the platform.
Once that late reply is received the channel ownership is given back
to the agent and any pending request is then allowed to proceed and
overwrite the SMT area of the just delivered late reply; then the wait
for the reply to the new request starts.
It has been observed that the spurious IRQ related to the late reply can
be wrongly associated with the freshly enqueued request: when that happens
the SCMI stack in-flight lookup procedure is fooled by the fact that the
message header now present in the SMT area is related to the new pending
transaction, even though the real reply has still to arrive.
This race-condition on the A2P channel can be detected by looking at the
channel status bits: a genuine reply from the platform will have set the
channel free bit before triggering the completion IRQ.
Add a consistency check to validate such condition in the A2P ISR.
Reported-by: Xinglong Yang <xinglong.yang@cixtech.com>
Closes: https://lore.kernel.org/all/PUZPR06MB54981E6FA00D82BFDBB864FBF08DA@PUZPR06MB5498.apcprd06.prod.outlook.com/
Fixes: 5c8a47a5a9 ("firmware: arm_scmi: Make scmi core independent of the transport type")
Cc: stable@vger.kernel.org # 5.15+
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Tested-by: Xinglong Yang <xinglong.yang@cixtech.com>
Link: https://lore.kernel.org/r/20231220172112.763539-1-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 964946b888 ]
The ending NULL is not taken into account by strncat(), so switch to
snprintf() to correctly build 'debug_name'.
Using snprintf() also makes the code more readable.
Fixes: aa276781a6 ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/7158db0a4d7b19855ddd542ec61b666973aad8dc.1698660720.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 271f2a4a95 ]
The efi_relocate_kernel() may load the PIE kernel to anywhere, the
loaded address may not be equal to link address or
EFI_KIMG_PREFERRED_ADDRESS.
Acked-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Wang Yao <wangyao@lemote.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 50d7cdf7a9 ]
River reports boot hangs with v6.6 and v6.7, and the bisect points to
commit
a1b87d54f4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot")
which moves the memory allocation and kernel decompression from the
legacy decompressor (which executes *after* ExitBootServices()) to the
EFI stub, using boot services for allocating the memory. The memory
allocation succeeds but the subsequent call to decompress_kernel() never
returns, resulting in a failed boot and a hanging system.
As it turns out, this issue only occurs when physical address
randomization (KASLR) is enabled, and given that this is a feature we
can live without (virtual KASLR is much more important), let's disable
the physical part of KASLR when booting on AMI UEFI firmware claiming to
implement revision v2.0 of the specification (which was released in
2006), as this is the version these systems advertise.
Fixes: a1b87d54f4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218173
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
The system firmware changed the logic and moved to support edge events,
so we need update driver to know what events needs to support.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
The system firmware board control moved to support falling edge,
rising edge for board control events. So update the firmware
driver to support it.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Moved the dev-ctx creation & misc-dev registration, late
in the probe.
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
Reviewed-by: Vabhav Sharma <vabhav.sharma@nxp.com>
Clean-up of the misc-devices from the probe cleanup.
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
Reviewed-by: Vabhav Sharma <vabhav.sharma@nxp.com>
[ Upstream commit 77f5032e94 ]
The multiplier is already promoted to unsigned long, however the
frequency calculations done when using level indexing mode doesn't
use the multiplier computed. It instead hardcodes the multiplier
value of 1000 at all the usage sites.
Clean that up by assigning the multiplier value of 1000 when using
the perf level indexing mode and update the frequency calculations to
use the multiplier instead. It should fix the possible frequency
truncation for all the values greater than or equal to 4GHz on 64-bit
machines.
Fixes: 31c7c1397a ("firmware: arm_scmi: Add v3.2 perf level indexing mode support")
Reported-by: Sibi Sankar <quic_sibis@quicinc.com>
Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis@quicinc.com/
Cc: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20231130204343.503076-2-sudeep.holla@arm.com
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 033ca4de12 ]
Let's simplify the code in scmi_dvfs_device_opps_add() by using
dev_pm_opp_remove_all_dynamic() in the error path.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230925131715.138411-8-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Stable-dep-of: 77f5032e94 ("firmware: arm_scmi: Fix possible frequency truncation when using level indexing mode")
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 8e3c98d918 ]
Fix the possible frequency truncation for all values equal to or greater
4GHz on 64bit machines by updating the multiplier 'mult_factor' to
'unsigned long' type. It is also possible that the multiplier itself can
be greater than or equal to 2^32. So we need to also fix the equation
computing the value of the multiplier.
Fixes: a9e3fbfaa0 ("firmware: arm_scmi: add initial support for performance protocol")
Reported-by: Sibi Sankar <quic_sibis@quicinc.com>
Closes: https://lore.kernel.org/all/20231129065748.19871-3-quic_sibis@quicinc.com/
Cc: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20231130204343.503076-1-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3d99ed6072 ]
Similar to other protocol ops, it's useful for an scmi module driver to get
some generic information of a performance domain. Therefore, let's add a
new callback to provide this information. The information is currently
limited to the name of the performance domain and whether the set-level
operation is supported, although this can easily be extended if we find the
need for it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230825112633.236607-3-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Stable-dep-of: 8e3c98d918 ("firmware: arm_scmi: Fix frequency truncation by promoting multiplier type")
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e9090e70e6 ]
Similar to other protocol ops, it's useful for an scmi module driver to get
the number of supported performance domains, hence let's make this
available by adding a new perf protocol callback. Note that, a user is
being added from subsequent changes.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230825112633.236607-2-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Stable-dep-of: 8e3c98d918 ("firmware: arm_scmi: Fix frequency truncation by promoting multiplier type")
Signed-off-by: Sasha Levin <sashal@kernel.org>
currently, the PM support of peripherals in the NETCMIX is not
ready yet, so we may need to keep netcmix PD always on for now.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
handling in Get SoC Info IOCTL handler
Fixed the error handling for Get SoC Info IOCTL handler
Signed-off-by: Rahul Kumar Yadav <rahulkumar.yadav@nxp.com>
[ Upstream commit 01b1e3ca0e ]
When a task needs to accept memory it will scan the accepting_list
to see if any ranges already being processed by other tasks overlap
with its range. Due to an off-by-one in the range comparisons, a task
might falsely determine that an overlapping range is being accepted,
leading to an unnecessary delay before it begins processing the range.
Fix the off-by-one in the range comparison to prevent this and slightly
improve performance.
Fixes: 50e782a86c ("efi/unaccepted: Fix soft lockups caused by parallel memory acceptance")
Link: https://lore.kernel.org/linux-mm/20231101004523.vseyi5bezgfaht5i@amd.com/T/#me2eceb9906fcae5fe958b3fe88e41f920f8335b6
Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
This is the 6.6.3 stable release
* tag 'v6.6.3': (526 commits)
Linux 6.6.3
drm/amd/display: Change the DMCUB mailbox memory location from FB to inbox
drm/amd/display: Clear dpcd_sink_ext_caps if not set
...
Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
Conflicts:
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
drivers/usb/dwc3/core.c
This is the 6.6.2 stable release
* tag 'v6.6.2': (634 commits)
Linux 6.6.2
btrfs: make found_logical_ret parameter mandatory for function queue_scrub_stripe()
btrfs: use u64 for buffer sizes in the tree search ioctls
...
Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
Conflicts:
drivers/clk/imx/clk-imx8mq.c
drivers/clk/imx/clk-imx8qxp.c
drivers/media/i2c/ov5640.c
drivers/misc/pci_endpoint_test.c
ARM SCMI Spec 3.2 introduces Clock Get Permission command. This patch
is to add the support. For clock enable/disable, directly return zero
if not allow to config. For rate & parent set, directly return -EACCES
if not allow to set.
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
commit 3337a6fea2 upstream.
Per the "SMC calling convention specification", the 64-bit calling
convention can only be used when the client is 64-bit. Whereas the
32-bit calling convention can be used by either a 32-bit or a 64-bit
client.
Currently during SCM probe, irrespective of the client, 64-bit calling
convention is made, which is incorrect and may lead to the undefined
behaviour when the client is 32-bit. Let's fix it.
Cc: stable@vger.kernel.org
Fixes: 9a434cee77 ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions")
Reviewed-By: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
Link: https://lore.kernel.org/r/20230925-scm-v3-1-8790dff6a749@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The SM MISC driver is the i.MX SCMI MISC protocol device driver part,
supports ctrl set, ctrl get, and request notification event.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Support i.MX SM MISC Control Protocol which includes set, get
and notification.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Separate the RTC part into a standalone function to prepare for
adding button feature
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Drop global variable by using device driver data to make
code cleaner.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
"bbm_rtc"->"bbm", since the driver is going to support rtc and powerkey
both.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Move the report structure to header file which will be used by consumers
Code style cleanup
Correct button report
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Sometimes there are rx timeout during scmi xfer, enlarge the rx
timeout from 30ms to 1000ms.
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
[ Upstream commit ea608a01d4 ]
Add suspend hook and a 'suspended' field in the 'struct tegra_bpmp'
to mark if BPMP is suspended. Also, add a 'flags' field in the
'struct tegra_bpmp_message' whose 'TEGRA_BPMP_MESSAGE_RESET' bit can be
set from the Tegra MC driver to signal that the reset of BPMP IPC
channels is required before sending MRQ to the BPMP FW. Together both
the fields allow us to handle any requests that might be sent too soon
as they can cause hang during system resume.
One case where we see BPMP requests being sent before the BPMP driver
has resumed is the memory bandwidth requests which are triggered by
onlining the CPUs during system resume. The CPUs are onlined before the
BPMP has resumed and we need to reset the BPMP IPC channels to handle
these requests.
The additional check for 'flags' is done to avoid any un-intended BPMP
IPC reset if the tegra_bpmp_transfer*() API gets called during suspend
sequence after the BPMP driver is suspended.
Fixes: f41e1442ac ("cpufreq: tegra194: add OPP support and set bandwidth")
Co-developed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 2d698e8b4f ]
An FF-A ABI could support both the SMC32 and SMC64 conventions.
A callee that runs in the AArch64 execution state and implements such
an ABI must implement both SMC32 and SMC64 conventions of the ABI.
So the FF-A drivers will need the option to choose the mode irrespective
of FF-A version and the partition execution mode flag in the partition
information.
Let us remove the check on the FF-A version for allowing the selection
of 32bit mode of messaging. The driver will continue to set the 32-bit
mode if the partition execution mode flag specified that the partition
supports only 32-bit execution.
Fixes: 106b11b1cc ("firmware: arm_ffa: Set up 32bit execution mode flag using partiion property")
Link: https://lore.kernel.org/r/20231005142823.278121-1-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7d0bc6360f ]
Commit 19b8766459 ("firmware: arm_ffa: Fix FFA device names for logical
partitions") added an ID to the FFA device using ida_alloc() and append
the same to "arm-ffa" to make up a unique device name. However it missed
to stash the id value in ffa_dev to help freeing the ID later when the
device is destroyed.
Due to the missing/unassigned ID in FFA device, we get the following
warning when the FF-A device is unregistered.
| ida_free called for id=0 which is not allocated.
| WARNING: CPU: 7 PID: 1 at lib/idr.c:525 ida_free+0x114/0x164
| CPU: 7 PID: 1 Comm: swapper/0 Not tainted 6.6.0-rc4 #209
| pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
| pc : ida_free+0x114/0x164
| lr : ida_free+0x114/0x164
| Call trace:
| ida_free+0x114/0x164
| ffa_release_device+0x24/0x3c
| device_release+0x34/0x8c
| kobject_put+0x94/0xf8
| put_device+0x18/0x24
| klist_devices_put+0x14/0x20
| klist_next+0xc8/0x114
| bus_for_each_dev+0xd8/0x144
| arm_ffa_bus_exit+0x30/0x54
| ffa_init+0x68/0x330
| do_one_initcall+0xdc/0x250
| do_initcall_level+0x8c/0xac
| do_initcalls+0x54/0x94
| do_basic_setup+0x1c/0x28
| kernel_init_freeable+0x104/0x170
| kernel_init+0x20/0x1a0
| ret_from_fork+0x10/0x20
Fix the same by actually assigning the ID in the FFA device this time
for real.
Fixes: 19b8766459 ("firmware: arm_ffa: Fix FFA device names for logical partitions")
Link: https://lore.kernel.org/r/20231003085932.3553985-1-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7b7a224b1b ]
The TI-SCI message protocol provides a way to communicate between
various compute processors with a central system controller entity. It
provides the fundamental device management capability and clock control
in the SOCs that it's used in.
The remove function failed to do all the necessary cleanup if
there are registered users. Some things are freed however which
likely results in an oops later on.
Ensure that the driver isn't unbound by suppressing its bind and unbind
sysfs attributes. As the driver is built-in there is no way to remove
device once bound.
We can also remove the ti_sci_remove call along with the
ti_sci_debugfs_destroy as there are no callers for it any longer.
Fixes: aa276781a6 ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol")
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Closes: https://lore.kernel.org/linux-arm-kernel/20230216083908.mvmydic5lpi3ogo7@pengutronix.de/
Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230921091025.133130-1-d-gole@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Add support for i.MX95 to use ELE Baseline APIs exposed by EdgeLock
Enclave Firmware.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
scmi-pinctrl driver implements pinctrl driver interface and using
SCMI protocol to redirect messages from pinctrl subsystem SDK to
SCMI platform firmware, which does the changes in HW.
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
Acked-by: Nitin Garg <nitin.garg_3@nxp.com>
i.MX SCMI protocol is to manage RTC and BUTTON in BBNSM module
which is controlled by system controller.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Nitin Garg <nitin.garg_3@nxp.com>
The firmware may export flags to indicate whether the clock
is allowed to set rate, set parent, enable/disable from the Agent.
If Agent is not allowed to enable/disable, directly return success.
If Agent is not allowed to set rate/parent, directly return -EACCES to
avoid SCMI RPC calls.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Nitin Garg <nitin.garg_3@nxp.com>
Fixed the Secure Enclave FW driver probe cleanup.
The release of reserved memory device and RESERVED_DMA_POOL
flag unset from priv flags, must be after DMA free.
Signed-off-by: Rahul Kumar Yadav <rahulkumar.yadav@nxp.com>
Some IMEM region is lost during kernel power down. Due to this,
firmware's functionaity cannot work correctly.
Saving encrypted IMEM region in kernel memory during power down,
and restore IMEM region on resume.
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
The Edgelock Enclave , is the secure enclave embedded in the SoC
to support the features like HSM, SHE & V2X, using message based
communication channel.
ELE FW communicates on a dedicated MU with application core where
kernel is running. It exists on specific i.MX processors. e.g.
i.MX8ULP, i.MX93.
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
In ele-mu driver:
- Command lock is locked in process-context, while
- Command lock is unlocked as part of call-back function associated with the mail-box
interrupt.
To fix the issue, moving the unlocking of command lock from
interrupt-context to process-context.
Squashed:
firmware: imx: fix coverity issue in ele-mu
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
The allocated Shared Memory contain the API REQ and RESP
data, even after the required data is copied from/to user buffers,
during HSM APIs CMD/RESP.
There is no further use of this data in Shared Memory,
but possible that this data get retrieved in certain cases.
Memset the Shared Memory space allocated for Copying Data
from/to User Buffers during HSM APIs CMD/RESP.
Signed-off-by: Rahul Kumar Yadav <rahulkumar.yadav@nxp.com>
For i.MX93 A1, the FW initialization API is mandatory to called once.
Later, this API will be made mandatory for i.MX8ULP A2, & i.MX93 A0.
LF-9154: ele-mu: api call to initialize firmware as part of ele-mu
probing.
FIXME: The API handling needs to be fixed as per future definitive changes
in FW.
Squashed:
LF-9356: firmware: ele-mu: fix for init fw api.
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
FW API(s) are handled differently as compared to base/rom api(s).
With increased number of fw api(s) requirement in driver, a fw file
to deal with fw api(s), is used.
lf-9154: ele-fw: moved fw rng api to file maintained for fw api(s).
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Currently two user buffer types are avilable which
can either be input or output.
Add new buffer type which is both input and output
acting as input to ELE and output to ELE library.
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
Reviewed-by: Gaurav Jain <gaurav.jain@nxp.com>
Some IMEM region is lost during power down, due to this
ELE functionaity cannot be used correctly.
so save encrypted IMEM region in kernel memory during power down,
and restore IMEM region on resume.
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: Varun Sethi <v.sethi@nxp.com>
during suspend this commands must be sent with EXPORT to save the IMEM.
during resume this commands must be sent with IMPORT to retrieve the IMEM.
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: Varun Sethi <v.sethi@nxp.com>
Created list of all dev-ctx during ele mu driver probe.
on driver resume, this list is used to wakeup
all the dev-ctx.
This way all dev-ctx resume their task.
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: Varun Sethi <v.sethi@nxp.com>
- removed static from imx_ele_msg_send_rcv api.
it is used to send and receive message over message
unit(mu) to communicate with S40x.
making this non static so other driver can use this
api to interact with S40x.
- moved the inclusion of mailbox_client.h to ele_mu.h
- added ele_get_trng_state to read the TRNG state.
ele mu driver use this to check if TRNG entropy is valid
and ready to be read.
- added ele_start_rng to start the initialization of the Sentinel RNG.
ele mu driver use this to start Sentinel RNG when trng state
is not valid.
- added ele_trng_enable in ele mu driver for initializing sentinel TRNG.
- added ele_trng_init to register Hardware Random Number Generator driver
- added ele_get_random to proceed with random number generation operation.
ele hwrng driver use this to read the random number with Sentinel.
Squashed:
LF-7786-1: firmware: imx: ele: split ele_trng_enable code
LF-8559 firmware: imx: ele: Update RNG request id
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: Varun Sethi <V.Sethi@nxp.com>
LF-6569-2: imx: ele: use get info of ELE Baseline API to get SoC revision
On the latest i.MX8ULP, replace hardcoded SoC revision with the value
getting from ELE Baseline API.
LF-6665-1: imx: only iMX8ULP soc device is registered in ele_mu.c
Only iMX8ULP soc device is registered in ele_mu_probe() so that restrict
other soc devices from being registered by socdev.
Fixes: 781095d1241c ("firmware: imx: ele: use get info of ELE Baseline
API to get SoC revision")
LF-6684: imx: hardcode revision of soc when get info API fails
When get info API fails, iMX8ULP soc device is not be registered, and
insmod the modules that depend on it will make mistakes. So that
set revision to be A0 by default to avoid this issue.
Squashed:
LF-6744 firmware: coverity fix ele-mu
LF-9012: fix rom-get-info failure
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
The ELE Ping message can be sent to ELE at any time to
verify ELE is alive This ping msg must be sent at least once
every day (24 hours). So add a delay work with 1 hour interval
for this purpose.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Ping message can be sent to ELE at any time to verify
ELE is alive, add it into the ele base msg.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com>
- Added f_ops read-write
- added ioctl to
-- Allcate IO buffer
-- to get MU info
- Update the call back function:
- for receiving message from ELE
- for receiving response to the sent message via
-- misc device context (from userspace)
-- from kernel space.
Squashed:
LF-6609-5 firmware: imx: updated ele mu driver
LF-7428 firmware: fix-up with the clean-up to null
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Rahul Kumar Yadav <rahulkumar.yadav@nxp.com>
- Added the character driver based on miscellenous device
in the Secure enclave to enable communication from user-space
with EdgeLock Enclave (ELE) kernel driver.
- Added the support to invoke the base API(s) offered by
ELE.
-- Common function to created header.
-- Common function to:
--- send/receive the message.
--- to apply the mutex locks.
Squashed:
MA-20107-10 firmware: imx: Support building el_enclave driver as module
LF-9476-1 ele_base_msg: handle common fuse with special id
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Zhipeng Wang <zhipeng.wang_1@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Export the API to configure the group priority of a
dma channel via RPC call to SCU.
Reviewed-by: Han Xu <han.xu@nxp.com>
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
Register a i.MX8ULP SoC device in s400-api.c.
Squash: MLK-25620 imx8ulp: soc: update imx8ulp soc device attribute
Reviewed-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>
(cherry picked from commit 3bc399ee42)
In the Sentinel application, the security subsystem uses S4 MU-AP to
communicate and coordinate with the SoC host processor. The s400-api
firmware driver provides the services to transmit data to and receive
data from the S4 MU-AP.
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>
(cherry picked from commit 9745b4a997)
SCU IMX_SC_MISC_FUNC_UNIQUE_ID don't return value by scu
return value from SCU is undefined.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
In order for a message sent to a V2X MU, the value indication the
type of the message chagne for each MU addressed.
This patch adds the read of the values from the device tree or
uses the default values which works with SECO MU.
Signed-off-by: Stéphane Dion <stephane.dion_1@nxp.com>
This patch adds the driver to interact with the different
APIs exposed by the SECO using a shared Messaging Unit.
The driver exposes some char devices in user space allowing
a user to send message to the SECO and read its response.
The driver uses the mailbox framework instead of directly
configuring the MU.
Squash:
HSM-292 firmware: imx: seco_mu: Increase MAX_DATA_SIZE_PER_USER
MLK-23421: fw: imx: seco_mu: Use fast IPC
MLK-23635: fw: imx: seco_mu: Fix messages at boot
HSM-267-1: fw: imx: seco_mu: Handle error code in mailbox rx callback
MLK-23421: fw: imx: seco_mu: Add the driver if IMX_SCU is set
Signed-off-by: Silvano di Ninno <silvano.dininno@nxp.com>
Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Leonard Crestez <leonard.crestez@nxp.com>
Signed-off-by: Hugo Dupras <hugo.dupras@nxp.com>
Reviewed-by: Stéphane Dion <stephane.dion_1@nxp.com>
Add imx_sc_rm_get_partition to get the runtime partition number.
Reviewed-by: zhang sanshan <pete.zhang@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
We use hvc to let xen handle the scfw api call for dom0.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
[ Aisheng: fix minior conflicts due to
51f5afabc0 ("firmware: imx: Skip return value check for some special SCU firmware APIs") ]
Sign-off-by: Dong Aisheng <aisheng.dong@nxp.com>
SCMI v3.2 spec introduces CLOCK_POSSIBLE_PARENTS_GET, CLOCK_PARENT_SET
and CLOCK_PARENT_GET. Add support for these to enable clock parents
and use them in the clock driver.
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20231004-scmi-clock-v3-v5-1-1b8a1435673e@nxp.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
It is very confusing to use *_v2 for everything applicable until SCMI
clock protocol version v2.0 including v1.0 for example. So let us rename
such that *_v2 is used only for SCMI clock protocol v2.1 onwards. Also
add comment to indicate the same explicitly.
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20230925101557.3839860-1-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
To allow a consumer driver to use the OPP library to scale the performance
for its device, let's dynamically add the OPP table when the device gets
attached to its SCMI performance domain.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230925131715.138411-10-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
To enable the performance level to be used for OPPs, let's convert into
using the dev_pm_opp_add_dynamic() API when creating them. This will be
particularly useful for the SCMI performance domain, as shown through
subsequent changes.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230925131715.138411-9-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Let's simplify the code in scmi_dvfs_device_opps_add() by using
dev_pm_opp_remove_all_dynamic() in the error path.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230925131715.138411-8-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
To enable support for performance scaling (DVFS) for generic devices with
the SCMI performance protocol, let's add an SCMI performance domain. This
is being modelled as a genpd provider, with support for performance scaling
through genpd's ->set_performance_state() callback.
Note that, this adds the initial support that allows consumer drivers for
attached devices, to vote for a new performance state via calling the
dev_pm_genpd_set_performance_state(). However, this should be avoided as
it's in most cases preferred to use the OPP library to vote for a new OPP
instead. The support using the OPP library isn't part of this change, but
needs to be implemented from subsequent changes.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230919121605.7304-1-ulf.hansson@linaro.org
[Move perf domain driver to firmware]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Similar to other protocol ops, it's useful for an scmi module driver to get
some generic information of a performance domain. Therefore, let's add a
new callback to provide this information. The information is currently
limited to the name of the performance domain and whether the set-level
operation is supported, although this can easily be extended if we find the
need for it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230825112633.236607-3-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Similar to other protocol ops, it's useful for an scmi module driver to get
the number of supported performance domains, hence let's make this
available by adding a new perf protocol callback. Note that, a user is
being added from subsequent changes.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230825112633.236607-2-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
There are no longer any users of the ->device_domain_id() ops in the
scmi_perf_proto_ops, therefore let's remove it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230825112633.236607-6-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Most scmi_perf_proto_ops are already using an "u32 domain" as an
in-parameter to indicate what performance domain we shall operate upon.
However, some of the ops are using a "struct device *dev", which means that
an additional OF parsing is needed each time the perf ops gets called, to
find the corresponding domain-id.
To avoid the above, but also to make the code more consistent, let's
replace the in-parameter "struct device *dev" with an "u32 domain". Note
that, this requires us to make some corresponding changes to the scmi
cpufreq driver, so let's do that too.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/20230825112633.236607-5-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Some recently added SCMI protocols needs an additional flags parameter to
be able to properly configure the command used to query the extended name
of a resource.
Modifed from:
https://lore.kernel.org/lkml/318eb79c7e1ddb1f964a901e778
a0475bf18c85b.1691518313.git.oleksii_moisieiev@epam.com/
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Expose a couple of new SCMI Clock operations to get and set OEM specific
clock configurations when talking to an SCMI v3.2 compliant.
Issuing such requests against an SCMI platform server not supporting v3.2
extension for OEM specific clock configurations will fail.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20230826125308.462328-7-cristian.marussi@arm.com
Acked-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Support Clock .state_get operation against SCMI platform servers that do
not support v3.2 CONFIG_GET dedicated command: while talking with these
platforms the command CLOCK_ATTRIBUTES can be used to gather the current
clock states.
Note that, in case of shared resources, the retrieved clock state 'flavour'
(virtual vs physical) depends on the backend SCMI platform server specific
kind of implementation.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20230826125308.462328-5-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add support for v3.2 Clock CONFIG_GET command and related new clock
protocol operation state_get() to retrieve the status of a clock.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20230826125308.462328-4-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
SCMI v3.2 introduces a new Clock CONFIG_SET message format that can
optionally carry also OEM specific configuration values beside the usual
clock enable/disable requests.
Refactor internal helpers and add support to use such new format when
talking to a v3.2 compliant SCMI platform.
Support existing enable/disable operations across different Clock protocol
versions: this patch still does not add protocol operations to support the
new OEM specific optional configuration capabilities.
No functional change for the SCMI drivers users of the related enable and
disable clock operations.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20230826125308.462328-3-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
SCMI Clock enable/disable operations come in 2 different flavours which
simply just differ in how the underlying SCMI transactions is carried on:
atomic or not.
Currently we expose such SCMI operations through 2 distinctly named
wrappers, that, in turn, are wrapped into another couple of similarly and
distinctly named callbacks inside SCMI Clock driver user.
Reduce the churn of duplicated wrappers by adding a param to SCMI Clock
enable/disable operations to ask for atomic operation while removing the
_atomic version of such operations.
No functional change.
CC: Michael Turquette <mturquette@baylibre.com>
CC: Stephen Boyd <sboyd@kernel.org>
CC: linux-clk@vger.kernel.org
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20230826125308.462328-2-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
on i.MX8QM 1.0/1.1,TLB maintenance through DVM messages over ARADDR channel,
some bits (see the following) will be corrupted:
ASID[15:12] VA[48:45] VA[44:41] VA[39:36]
This issue will result in the TLB aintenance across the clusters not working
as expected due to some VA and ASID bits get corrupted
The SW workaround is: use the vmalle1is if VA larger than 36bits or
ASID[15:12] is not zero, otherwise, we use original TLB maintenance path.
Note: To simplify the code, we did not check VA[40] bit specifically
[ Leo: Separated arch changes into a separate patch ]
Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
Reviewed-by: Anson Huang <anson.huang@nxp.com>
A couple of platforms have some last-minute fixes for 6.7, in particular
- riscv gets some fixes for noncoherent DMA on the renesas and thead
platforms and dts fix for SPI on the visionfive 2 board
- Qualcomm Snapdragon gets three dts fixes to address board specific
regressions on the pmic and gpio nodes
- Rockchip platforms get multiple dts fixes to address issues on
the recent rk3399 platform as well as the older rk3128 platform
that apparently regressed a while ago.
- TI OMAP gets some trivial code and dts fixes and a regression fix
for the omap1 ams-delta modem
- NXP i.MX firmware has one fix for a use-after-free but in its
error handling.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmU6hBgACgkQYKtH/8kJ
Uiejsw//ZqOVJwK6fQRR2tx8k8Tg5x7q1KlpuxNW6JAbsYcNZF8OeEQYvp+fZP/c
x8fDYYAc/02w++2U5QXGWm615359GKCdWxPivop51FJ7Try1Ij0KC3MJz4U2F65J
ZdwnVsAukYRDzNTmDu08BRsLXjsglQhZnuXxshsZcoe8mZRnDukYVPMmW12thitY
6R/c77kW1fvjxJt2M4vbqbOoXB1hXlsGl/l0HrAqN3OyqDD7lsak3byI1+x5nXzU
n9EA9sC5wnnj/06LpW/b5OSBWPgteIRJauTsEy/zLdD1oPWgMT3kyjG4GZBK3bXo
8pfeuom7ujqaWsDmeIPlwWRNChGy99XmlGaC+dciD1sVMY2/phQfucBlddGl5JDX
UO8EwATQ7Hy+PZwjjatwdon4sngs5MwHiGpmNhtEwAARQSLhLsvY290RCZFCoXgb
8rio7je/c/wgT28KJb/kXZHYoaNVl9Za24l+oyLCTzel5CGON4vE6Y1nPO9+tcyz
fttxABZs+DN5BbmABuVVrTRJUGCBCsNWZY33vgYCCdZditXTYWfOH6BkO4NtYzsI
QUG2mkykTfmxWnwmWODShAEcpJTP5ck9eZK2edujEK9I0m6dLHaUbZPNoXkpe4l3
U1F4QnGGCjff6o4W9bWbOj/SgFAC9q9C7KBYIom3hpN13Ik3rpA=
=6/SQ
-----END PGP SIGNATURE-----
Merge tag 'soc-fixes-6.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC fixes from Arnd Bergmann:
"A couple of platforms have some last-minute fixes, in particular:
- riscv gets some fixes for noncoherent DMA on the renesas and thead
platforms and dts fix for SPI on the visionfive 2 board
- Qualcomm Snapdragon gets three dts fixes to address board specific
regressions on the pmic and gpio nodes
- Rockchip platforms get multiple dts fixes to address issues on the
recent rk3399 platform as well as the older rk3128 platform that
apparently regressed a while ago.
- TI OMAP gets some trivial code and dts fixes and a regression fix
for the omap1 ams-delta modem
- NXP i.MX firmware has one fix for a use-after-free but in its error
handling"
* tag 'soc-fixes-6.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (25 commits)
soc: renesas: ARCH_R9A07G043 depends on !RISCV_ISA_ZICBOM
riscv: only select DMA_DIRECT_REMAP from RISCV_ISA_ZICBOM and ERRATA_THEAD_PBMT
riscv: RISCV_NONSTANDARD_CACHE_OPS shouldn't depend on RISCV_DMA_NONCOHERENT
riscv: dts: thead: set dma-noncoherent to soc bus
arm64: dts: rockchip: Fix i2s0 pin conflict on ROCK Pi 4 boards
arm64: dts: rockchip: Add i2s0-2ch-bus-bclk-off pins to RK3399
clk: ti: Fix missing omap5 mcbsp functional clock and aliases
clk: ti: Fix missing omap4 mcbsp functional clock and aliases
ARM: OMAP1: ams-delta: Fix MODEM initialization failure
soc: renesas: Make ARCH_R9A07G043 depend on required options
riscv: dts: starfive: visionfive 2: correct spi's ss pin
firmware/imx-dsp: Fix use_after_free in imx_dsp_setup_channels()
ARM: OMAP: timer32K: fix all kernel-doc warnings
ARM: omap2: fix a debug printk
ARM: dts: rockchip: Fix timer clocks for RK3128
ARM: dts: rockchip: Add missing quirk for RK3128's dma engine
ARM: dts: rockchip: Add missing arm timer interrupt for RK3128
ARM: dts: rockchip: Fix i2c0 register address for RK3128
arm64: dts: rockchip: set codec system-clock-fixed on px30-ringneck-haikou
arm64: dts: rockchip: use codec as clock master on px30-ringneck-haikou
...
- don't try to print warnings to the console when it is no longer
available
- fix theoretical memory leak in SSDT override handling
- make sure that the boot_params global variable is set before the KASLR
code attempts to hash it for 'randomness'
- avoid soft lockups in the memory acceptance code
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQQm/3uucuRGn1Dmh0wbglWLn0tXAUCZTKmyAAKCRAwbglWLn0t
XOvWAQCz+MYqhf3HbmsyuzEV/HWxEw9gf+KGqSN9wmCrOI5nRAEA7pIWUpZ2e6Jt
eW/6DiyPZ+o7xLMX6J01vLROmQt1ogo=
=iVui
-----END PGP SIGNATURE-----
Merge tag 'efi-fixes-for-v6.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi
Pull EFI fixes from Ard Biesheuvel:
"The boot_params pointer fix uses a somewhat ugly extern struct
declaration but this will be cleaned up the next cycle.
- don't try to print warnings to the console when it is no longer
available
- fix theoretical memory leak in SSDT override handling
- make sure that the boot_params global variable is set before the
KASLR code attempts to hash it for 'randomness'
- avoid soft lockups in the memory acceptance code"
* tag 'efi-fixes-for-v6.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
efi/unaccepted: Fix soft lockups caused by parallel memory acceptance
x86/boot: efistub: Assign global boot_params variable
efi: fix memory leak in krealloc failure handling
x86/efistub: Don't try to print after ExitBootService()
Michael reported soft lockups on a system that has unaccepted memory.
This occurs when a user attempts to allocate and accept memory on
multiple CPUs simultaneously.
The root cause of the issue is that memory acceptance is serialized with
a spinlock, allowing only one CPU to accept memory at a time. The other
CPUs spin and wait for their turn, leading to starvation and soft lockup
reports.
To address this, the code has been modified to release the spinlock
while accepting memory. This allows for parallel memory acceptance on
multiple CPUs.
A newly introduced "accepting_list" keeps track of which memory is
currently being accepted. This is necessary to prevent parallel
acceptance of the same memory block. If a collision occurs, the lock is
released and the process is retried.
Such collisions should rarely occur. The main path for memory acceptance
is the page allocator, which accepts memory in MAX_ORDER chunks. As long
as MAX_ORDER is equal to or larger than the unit_size, collisions will
never occur because the caller fully owns the memory block being
accepted.
Aside from the page allocator, only memblock and deferered_free_range()
accept memory, but this only happens during boot.
The code has been tested with unit_size == 128MiB to trigger collisions
and validate the retry codepath.
Fixes: 2053bc57f3 ("efi: Add unaccepted memory support")
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Michael Roth <michael.roth@amd.com
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Tested-by: Michael Roth <michael.roth@amd.com>
[ardb: drop unnecessary cpu_relax() call]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Now that the x86 EFI stub calls into some APIs exposed by the
decompressor (e.g., kaslr_get_random_long()), it is necessary to ensure
that the global boot_params variable is set correctly before doing so.
Note that the decompressor and the kernel proper carry conflicting
declarations for the global variable 'boot_params' so refer to it via an
alias to work around this.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
In the previous code, there was a memory leak issue where the
previously allocated memory was not freed upon a failed krealloc
operation. This patch addresses the problem by releasing the old memory
before setting the pointer to NULL in case of a krealloc failure. This
ensures that memory is properly managed and avoids potential memory
leaks.
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
setup_e820() is executed after UEFI's ExitBootService has been called.
This causes the firmware to throw an exception because the Console IO
protocol is supposed to work only during boot service environment. As
per UEFI 2.9, section 12.1:
"This protocol is used to handle input and output of text-based
information intended for the system user during the operation of code
in the boot services environment."
So drop the diagnostic warning from this function. We might add back a
warning that is issued later when initializing the kernel itself.
Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
dsp_chan->name and chan_name points to same block of memory,
because dev_err still needs to be used it,so we need free
it's memory after use to avoid use_after_free.
Fixes: e527adfb9b ("firmware: imx-dsp: Fix an error handling path in imx_dsp_setup_channels()")
Signed-off-by: Hao Ge <gehao@kylinos.cn>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
These are teh latest bug fixes that have come up in the soc tree.
Most of these are fairly minor. Most notably, the majority of
changes this time are not for dts files as usual.
- Updates to the addresses of the broadcom and aspeed entries in the
MAINTAINERS file.
- Defconfig updates to address a regression on samsung and a build
warning from an unknown Kconfig symbol
- Build fixes for the StrongARM and Uniphier platforms
- Code fixes for SCMI and FF-A firmware drivers, both of which had
a simple bug that resulted in invalid data, and a lesser fix for
the optee firmware driver
- Multiple fixes for the recently added loongson/loongarch "guts"
soc driver
- Devicetree fixes for RISC-V on the startfive platform, addressing
issues with NOR flash, usb and uart.
- Multiple fixes for NXP i.MX8/i.MX9 dts files, fixing problems
with clock, gpio, hdmi settings and the Makefile
- Bug fixes for i.MX firmware code and the OCOTP soc driver
- Multiple fixes for the TI sysc bus driver
- Minor dts updates for TI omap dts files, to address boot
time warnings and errors
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmUYkbMACgkQYKtH/8kJ
UieVvhAAxBNwvYsM7YCqmcD0xENAwMam3+zVEsDNac6yp4k1zrJxPItYeqx65qvj
de3/1toUcq5q/XN1MQYyIdHrL4QX/I3KG8+SJB/X9z0if882CUtC/1fd9d7Mj0hu
K7T7JZHDUj2rk+6Bh6sLRp6QmuS2KcKErYFlASXqqg49MddjbB8/QtYPZEAUOlmK
x4l9trnno42gvzjkNba/w1uiOA1WIwUp6d6VoM7oxIiFomHxBBZf1mzTgXaNDNvN
2vf+kumhQNvC3tKOUZNxps4N21N6kz0MAad/VcCKUyQ1bDTicdVwkTKUTrHs+hcu
EauWObm+fFfdSTflQ3R9+6ooDN70CCpDmS+ZdoFP/Nt+h9m/TcNYHp5mtr3gt9+O
cDkkGPKQyVBw0HjEG6yzEfYnPJ8w7v/+zpnie4Drc61i/kb8ETVNd9eOJTftvsFu
QcsANKdeZOc/64ZL27FD1ZZrvDWJsIDVG3dcX2+AgoZhjo0M3HGKv1LtWqJhvspU
lCzGNBsjcG/bQMupVxgomRhvg9hWWnXLTp949dOESecx4iUDEXl3nCo0+efXB2Tx
DNLnMEXC1F/B2GdYRUU61fmGVwIgItLJtyYFB8Miw+id+K0k8+uaklq2dHmLZOtq
FWbCB9oMks7q3lcEn1GJeIYFetuO+dmSEam/Hcg2hmW0Ke1ZZQI=
=HAuE
-----END PGP SIGNATURE-----
Merge tag 'soc-fixes-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC fixes from Arnd Bergmann:
"These are the latest bug fixes that have come up in the soc tree. Most
of these are fairly minor. Most notably, the majority of changes this
time are not for dts files as usual.
- Updates to the addresses of the broadcom and aspeed entries in the
MAINTAINERS file.
- Defconfig updates to address a regression on samsung and a build
warning from an unknown Kconfig symbol
- Build fixes for the StrongARM and Uniphier platforms
- Code fixes for SCMI and FF-A firmware drivers, both of which had a
simple bug that resulted in invalid data, and a lesser fix for the
optee firmware driver
- Multiple fixes for the recently added loongson/loongarch "guts" soc
driver
- Devicetree fixes for RISC-V on the startfive platform, addressing
issues with NOR flash, usb and uart.
- Multiple fixes for NXP i.MX8/i.MX9 dts files, fixing problems with
clock, gpio, hdmi settings and the Makefile
- Bug fixes for i.MX firmware code and the OCOTP soc driver
- Multiple fixes for the TI sysc bus driver
- Minor dts updates for TI omap dts files, to address boot time
warnings and errors"
* tag 'soc-fixes-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (35 commits)
MAINTAINERS: Fix Florian Fainelli's email address
arm64: defconfig: enable syscon-poweroff driver
ARM: locomo: fix locomolcd_power declaration
soc: loongson: loongson2_guts: Remove unneeded semicolon
soc: loongson: loongson2_guts: Convert to devm_platform_ioremap_resource()
soc: loongson: loongson_pm2: Populate children syscon nodes
dt-bindings: soc: loongson,ls2k-pmc: Allow syscon-reboot/syscon-poweroff as child
soc: loongson: loongson_pm2: Drop useless of_device_id compatible
dt-bindings: soc: loongson,ls2k-pmc: Use fallbacks for ls2k-pmc compatible
soc: loongson: loongson_pm2: Add dependency for INPUT
arm64: defconfig: remove CONFIG_COMMON_CLK_NPCM8XX=y
ARM: uniphier: fix cache kernel-doc warnings
MAINTAINERS: aspeed: Update Andrew's email address
MAINTAINERS: aspeed: Update git tree URL
firmware: arm_ffa: Don't set the memory region attributes for MEM_LEND
arm64: dts: imx: Add imx8mm-prt8mm.dtb to build
arm64: dts: imx8mm-evk: Fix hdmi@3d node
soc: imx8m: Enable OCOTP clock for imx8mm before reading registers
arm64: dts: imx8mp-beacon-kit: Fix audio_pll2 clock
arm64: dts: imx8mp: Fix SDMA2/3 clocks
...
A single fix to address scmi_perf_attributes_get() using the protocol
version even before it was populated and ending up with unexpected
bogowatts power scale.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmUUGkkACgkQAEG6vDF+
4phm7g/+LjCMNZ0uxp/qxcZszFJln2wO2MFnY2X55o/anFlLoMQdeDlzBgGGP5Ul
UmMo29Aq0n6FmPkrj2oV+3QR5oRKSauSbkLDxYGP4GVxpZ8zC8YotNV4z9XfxbnZ
+SoZflXFCO/P/lPq7MMVJNcB4WqQjUv+yg9uHaejN2kXwhmntxoUqYb+82TgL/No
Vb9rTkvRCLO6K/jxUgIWT0uwu1aBx7yOzx74Fe79IwWgGCdikk18hR13KhzsxnVz
FHgoGnoo3cffx6gZPKNTIH032pSn24JuYRxT+FCY8IXbZYAkeHG8L5AklFDBRcHs
zKOjnmAcPSNYDSaC5BpaJo6J7qbXnGiCUVZWlD5UzjVvOsdQRElDlQRpxwbAoRED
3jxOSAN8V1GnC5cZvAPmMKtJk/5/2tw3pxOg4fxuvXVhetwg4fEiFghTzZN3N028
yMpciPRU5M5EuROGLs6+NGdK93aLsDDYPnOoPe4jdBD77M0WcxrruC9I80wn6yQR
+qxwlooebt9WR+ZkOYnsIBsWcRbvn/dMvnotTM7Tm2gblK2uVmhySKjYR931/p1D
6gDOilbUebN/RN1CPcP1NzOVl0IuRblXe3Ps5TD7liwCCzVYxD5kwfIJMC6o8Cfr
QPkqtCRv4jPbUQdrGCOEDRD+GqiF3nNvuGUQ6mqBFFvR4h9NbPU=
=v9wZ
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmUVKAEACgkQYKtH/8kJ
UidgWRAA0D9EEbxqHt5WjBW75jifD09oUD1+XnyYCIVa9fyB11uInUJxAjG/xSGg
JSqK54TRnK32OpwFeClv6k38WdpRw3GemCBNxvAXrF4wN4f1xKD0O0rM46U0AoFb
fSqoO3TZN2wgOJbdPmIUSBJJ9To2jquQeKi+qDZ5o2utUfjVHfJqVIqpZR2SPTf2
vXoFRfPcx5rmSrXNX57U1pv1NCTp3y14RT2VJwzND/Nb8jMjxYQFWslBcFSJNTRn
oTzdSSP4W+XZOGF13N2pfuLe2mqqSnMHeXlBD9oMvgGfFO0gAQ1xc4V1CNc6tzjc
xrbhGYwEUqXqo+TJa8uLYbUE4aaPdkP4VBn3cNn/5BrkAooZwOAfRaNYoXFNRwZw
nZ3e0e6qKsyA/frOt7lqFU/J81HHxEQpEKg1bVqPpuviYNRNNfms4XPrtx9+DWPd
xdQoqUW3jGJ4yzgxh4V1ZDvIFP2/1C1gilayXxtHcoo9H3Grue9n6ApTcO1HJQaC
JIHIwSWn2PkxZ919fPmqJHY8bFLkjJHWYRM+oPrp/Cn5B3NLQ1ICGPbDRmS5x/Vs
mTBjjkwRVJcHmMLN+5/XdQYKRzrHAtKD8Um6V4nJ1iRkI7IQykGY4KHqmyxCRWMh
mcMsq89suKAAimy+kTmg1kP/OYR5zAMaikQx/QsmOYgxRdAGkHU=
=ZyGq
-----END PGP SIGNATURE-----
Merge tag 'scmi-fix-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Arm SCMI fix for v6.6
A single fix to address scmi_perf_attributes_get() using the protocol
version even before it was populated and ending up with unexpected
bogowatts power scale.
* tag 'scmi-fix-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Fixup perf power-cost/microwatt support
Link: https://lore.kernel.org/r/20230927121604.158645-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
It has been reported that the driver sets the memory region attributes
for MEM_LEND operation when the specification clearly states not to. The
fix here addresses the issue by ensuring the memory region attributes are
cleared for the memory lending operation.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmUUG70ACgkQAEG6vDF+
4pg0Og//dteLTtj/mHej4fIL3ih0qNN6Ih1NXlqfcgc4Yw7EcLhnKZabwGy3Ybdq
4egdPwHXLPMS7XAxg7y2WWoMA7+raFYp8vYOWOjHdTPmgDjzxHMybMP3J31RSjfL
gi4DoF8g2EF0bwtMvk0A3pTqgQG3YOfMupf9CLPZg5XOmPVDAq5R1zn3hu/Dz/ic
5nkJNkA3VCmLrSzfSEQtC8vDPT0pNID6sLCgByJvx6qqPKAlO6Mhpe1f93N2BMsK
Z24SjevzPHjGFS4MwaW8evDpdTuESUd0MQBV5/yCha8gvJOK2Q0629qLM5fpii7j
ZxHkGaj1pSj9zqCCKOxJVFanxTEJQo8dAbzz446jB7pBkeT4T4sIAsHe+Jw7QIOS
kFT3xOfZwYpCU7nJWEgOaDuNBlHFD5ZiP922tXatX6nj7gEopVpUSg0u1R9/BMHa
DLK3xaF/Gd38KFN52WBV98+jFyE9dUYVu1PLG+uJDvKyS6PoKKmRckNxdtPDpEeH
Lsez4ES9dbb2c+nCrAseUeuFW1D8HBEHo705MIGsefqfqISOrh1A3oj7gEwnv6ho
ZOLKbSHX3ufx3WOm4R8aFtRafP7ZL8X6ovQDCzzYhAitnF2bp+zfjJOkJv4X7OLV
jz8AtdwCT6qW5rg0PCDNo8CrAYN1GA0/+ria17JpKF37Pk5hdjQ=
=Flo6
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmUVJ9oACgkQYKtH/8kJ
UidcBRAApJskT2y1BVlZZTtyUuu9cck/dfGfzhP50XiO6m0YYr6W+RnLjWj4o/oc
5Ct7eJsqh8jZ2XbZQfXY/eojts/xyfFq48MBWBkuMECE3M5rsjkPTu1N+WOJiVUt
BlbLmwx5xNuK2JbSdHN/Et4xguau6ZbhZ08nW8+uHOJtxquUjCapWqN9r5cYki8V
NQhdaaT0/YlA4sMPsCN9HkEVR0VYlHkcQo9f8onXg93rUpK3p7hWhz5pUZDJEwZE
CSb+is4ADsNAzioLCTZh9MDMQoaduxQXzw8QjYKY6mxK1VIFDmDmblMl7UFARQs7
ufvqzGZpCqVNrjQK7+vHXakrG5hOA2VmMRhMt60KrY4AVTgpZYNzGqpIz7dlOuxd
8FDwjHEeYZXgtfUA6dxD19oRi49shO3HB34YrTbGi7GOOjuWJl4c3wJtR/Ps1vha
GFnggmOqjRFYi+YBzShCn/pZGgcAHWadcLn3zklCcnNaRj+2voXyqKOkDbuhteFs
4zt1ggvykeAQ8mU9+HwiwIZek9X7hsKI7bz2jKTV8uugqr5DDTnY7vwOtGvZochk
GBpEZH12e5Cf9QO74Nam5kvLJqpj3orhSul0jnWZ1R8n9Obv0IH/ytthctDnP4Ek
XFqGiBoQzDTNIjANcmr0UG46l+95J9Lbi7iyk+tX7z5+wVxkQ7U=
=MdPT
-----END PGP SIGNATURE-----
Merge tag 'ffa-fix-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Arm FF-A fix for v6.6
It has been reported that the driver sets the memory region attributes
for MEM_LEND operation when the specification clearly states not to. The
fix here addresses the issue by ensuring the memory region attributes are
cleared for the memory lending operation.
* tag 'ffa-fix-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_ffa: Don't set the memory region attributes for MEM_LEND
Link: https://lore.kernel.org/r/20230927121555.158619-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
As per the FF-A specification: section "Usage of other memory region
attributes", in a transaction to donate memory or lend memory to a single
borrower, if the receiver is a PE or Proxy endpoint, the owner must not
specify the attributes and the relayer will return INVALID_PARAMETERS
if the attributes are set.
Let us not set the memory region attributes for MEM_LEND.
Fixes: 82a8daaecf ("firmware: arm_ffa: Add support for MEM_LEND")
Reported-by: Joao Alves <joao.alves@arm.com>
Reported-by: Olivier Deprez <olivier.deprez@arm.com>
Link: https://lore.kernel.org/r/20230919-ffa_v1-1_notif-v2-13-6f3a3ca3923c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
- fix boot regression on SEV-SNP (and TDX) caused by a fix in the
preceding batch
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQQm/3uucuRGn1Dmh0wbglWLn0tXAUCZQ1ddAAKCRAwbglWLn0t
XOIQAP4nS3RWd2On40iOMpyfmKo8BmuM1smJC5r6xQTc55eORwEA3ezhbKZruxMp
bU2qR0yH/aGEtyOX0lDN0NIntplQdgI=
=ldKV
-----END PGP SIGNATURE-----
Merge tag 'efi-fixes-for-v6.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi
Pull EFI fix from Ard Biesheuvel:
"Follow-up fix for the unaccepted memory fix merged last week as part
of the first EFI fixes batch.
The unaccepted memory table needs to be accessible very early, even in
cases (such as crashkernels) where the direct map does not cover all
of DRAM, and so it is added to memblock explicitly, and subsequently
memblock_reserve()'d as before"
* tag 'efi-fixes-for-v6.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
efi/unaccepted: Make sure unaccepted table is mapped
A large collection of fixes around this time.
All small and mostly trivial fixes.
- Lots of fixes for the new -Wformat-truncation warnings
- A fix in ALSA rawmidi core regression and UMP handling
- Series of Cirrus codec fixes
- ASoC Intel and Realtek codec fixes
- Usual HD- and USB-audio quirks and AMD ASoC quirks
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmUMUWkOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE+hdxAA0+tcf9xj7Na58P3VCD0dCBddoJ4STModW8RZ
SnOevnjIMLa7TFKnxyBNWTgtBlKpaJ62c+/ZJJt0dgzDaYAX/6kGz9I9WN5w/81x
JKbXemtbv32h/STmE36G3j2pILzKMVo8Iew4aghga5t7QkZZuSfj5KPiKpg0lIE4
LGfAoaPUFvsgHGqKKP4Y2qOeGkR7LWJ6r66mtC0WMb5LNddPrdsWbscj0ZfeEceE
p3jQMk5Iw/d/8PueIdsVL0Epq8j46L+EKaNMgdG38eJsMxhhLnDoyZ4lRwIZ5Stg
X+BTFULw7v/ldp/vBOoJgQYkjI9g51T7H1h58oZP1xup68eE1+QVw2D/Jpx+zDv8
TZrp3YLlWMN3YVZKxKpum0AALGELYA1eSax94sifxwMOQ2P7ctDgVUVKq2mxiPWN
W+244dvoz1IB6ey22PRP7eSx015CHAtOosCPesSYs2M8OPsz0ckfxijz7PGcpqTD
7NFKAilG6lkMn638A4O1PG5l/DuMoIP8/W6JWeF83yCIxTvQVIcYdFxIku4rU8Lh
LbyHU6nV9pH+B2RDjZpPQNVNZfp/egFlLsKGaIc9Wqjuur7vjryXRNs2y2Xq/0jq
0xJsV8xoPj4WO2u4+sFkYNMZ5AjTPUGndGURA3QMMjsDUnAxTw6e4a5yf06V9hZU
ZaWVhRk=
=1MuW
-----END PGP SIGNATURE-----
Merge tag 'sound-6.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A large collection of fixes around this time.
All small and mostly trivial fixes.
- Lots of fixes for the new -Wformat-truncation warnings
- A fix in ALSA rawmidi core regression and UMP handling
- Series of Cirrus codec fixes
- ASoC Intel and Realtek codec fixes
- Usual HD- and USB-audio quirks and AMD ASoC quirks"
* tag 'sound-6.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (64 commits)
ALSA: hda/realtek - ALC287 Realtek I2S speaker platform support
ALSA: hda: cs35l56: Use the new RUNTIME_PM_OPS() macro
ALSA: usb-audio: scarlett_gen2: Fix another -Wformat-truncation warning
ALSA: rawmidi: Fix NULL dereference at proc read
ASoC: SOF: core: Only call sof_ops_free() on remove if the probe was successful
ASoC: SOF: Intel: MTL: Reduce the DSP init timeout
ASoC: cs42l43: Add shared IRQ flag for shutters
ASoC: imx-audmix: Fix return error with devm_clk_get()
ASoC: hdaudio.c: Add missing check for devm_kstrdup
ALSA: riptide: Fix -Wformat-truncation warning for longname string
ALSA: cs4231: Fix -Wformat-truncation warning for longname string
ALSA: ad1848: Fix -Wformat-truncation warning for longname string
ALSA: hda: generic: Check potential mixer name string truncation
ALSA: cmipci: Fix -Wformat-truncation warning
ALSA: firewire: Fix -Wformat-truncation warning for MIDI stream names
ALSA: firewire: Fix -Wformat-truncation warning for longname string
ALSA: xen: Fix -Wformat-truncation warning
ALSA: opti9x: Fix -Wformat-truncation warning
ALSA: es1688: Fix -Wformat-truncation warning
ALSA: cs4236: Fix -Wformat-truncation warning
...
Unaccepted table is now allocated from EFI_ACPI_RECLAIM_MEMORY. It
translates into E820_TYPE_ACPI, which is not added to memblock and
therefore not mapped in the direct mapping.
This causes a crash on the first touch of the table.
Use memblock_add() to make sure that the table is mapped in direct
mapping.
Align the range to the nearest page borders. Ranges smaller than page
size are not mapped.
Fixes: e7761d827e ("efi/unaccepted: Use ACPI reclaim memory for unaccepted memory table")
Reported-by: Hongyu Ning <hongyu.ning@intel.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
If mbox_request_channel_byname() fails, the memory allocated a few lines
above still need to be freed before going to the error handling path.
Fixes: 046326989a ("firmware: imx: Save channel name for further use")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Change the logging of each algorithm from info level to debug level.
On the original devices supported by this code there were typically only
one or two algorithms in a firmware and one or two DSPs so this logging
only used a small number of log lines.
However, for the latest devices there could be 30-40 algorithms in a
firmware and 8 DSPs being loaded in parallel, so using 300+ lines of log
for information that isn't particularly important to have logged.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230913160523.3701189-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The perf power scale value would currently be reported as bogowatts if the
platform firmware supports microwatt power scale and meets the perf major
version requirements. Fix this by populating version information in the
driver private data before the call to protocol attributes is made.
CC: Chandra Sekhar Lingutla <quic_lingutla@quicinc.com>
Fixes: 3630cd8130 ("firmware: arm_scmi: Add SCMI v3.1 perf power-cost in microwatts")
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20230811204818.30928-1-quic_sibis@quicinc.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
