[ Upstream commit 2593f7e0dc ]
Set ret = 0 on successful completion of the processing loop in
cs_dsp_load() and cs_dsp_load_coeff() to ensure that the function
returns 0 on success.
All normal firmware files will have at least one data block, and
processing this block will set ret == 0, from the result of either
regmap_raw_write() or cs_dsp_parse_coeff().
The kunit tests create a dummy firmware file that contains only the
header, without any data blocks. This gives cs_dsp a file to "load"
that will not cause any side-effects. As there aren't any data blocks,
the processing loop will not set ret == 0.
Originally there was a line after the processing loop:
ret = regmap_async_complete(regmap);
which would set ret == 0 before the function returned.
Commit fe08b7d508 ("firmware: cs_dsp: Remove async regmap writes")
changed the regmap write to a normal sync write, so the call to
regmap_async_complete() wasn't necessary and was removed. It was
overlooked that the ret here wasn't only to check the result of
regmap_async_complete(), it also set the final return value of the
function.
Fixes: fe08b7d508 ("firmware: cs_dsp: Remove async regmap writes")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20250323170529.197205-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit cb16dfed00 upstream.
Ben reports spurious EFI zboot failures on a system where physical RAM
starts at 0x0. When doing random memory allocation from the EFI stub on
such a platform, a random seed of 0x0 (which means no entropy source is
available) will result in the allocation to be placed at address 0x0 if
sufficient space is available.
When this allocation is subsequently passed on to the decompression
code, the 0x0 address is mistaken for NULL and the code complains and
gives up.
So avoid address 0x0 when doing random allocation, and set the minimum
address to the minimum alignment.
Cc: <stable@vger.kernel.org>
Reported-by: Ben Schneider <ben@bens.haus>
Tested-by: Ben Schneider <ben@bens.haus>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit da8d493a80 upstream.
Since the conversion to using the TZ allocator, the efivars service is
registered before the memory pool has been allocated, something which
can lead to a NULL-pointer dereference in case of a racing EFI variable
access.
Make sure that all resources have been set up before registering the
efivars.
Fixes: 6612103ec3 ("firmware: qcom: qseecom: convert to using the TZ allocator")
Cc: stable@vger.kernel.org # 6.11
Cc: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20250120151000.13870-1-johan+linaro@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit fbf10b86f6 ]
imx_scu_probe() calls of_parse_phandle_with_args(), but does not
release the OF node reference obtained by it. Add a of_node_put() call
after done with the node.
Fixes: f25a066d1a ("firmware: imx-scu: Support one TX and one RX")
Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 07e0d99a2f ]
When performing an iSCSI boot using IPv6, iscsistart still reads the
/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix
length is 64, this causes the shift exponent to become negative,
triggering a UBSAN warning. As the concept of a subnet mask does not
apply to IPv6, the value is set to ~0 to suppress the warning message.
Signed-off-by: Chengen Du <chengen.du@canonical.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2b90e7ace7 upstream.
Currently, when validating the mokvar table, we (re)map the entire table
on each iteration of the loop, adding space as we discover new entries.
If the table grows over a certain size, this fails due to limitations of
early_memmap(), and we get a failure and traceback:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220
...
Call Trace:
<TASK>
? __early_ioremap+0xef/0x220
? __warn.cold+0x93/0xfa
? __early_ioremap+0xef/0x220
? report_bug+0xff/0x140
? early_fixup_exception+0x5d/0xb0
? early_idt_handler_common+0x2f/0x3a
? __early_ioremap+0xef/0x220
? efi_mokvar_table_init+0xce/0x1d0
? setup_arch+0x864/0xc10
? start_kernel+0x6b/0xa10
? x86_64_start_reservations+0x24/0x30
? x86_64_start_kernel+0xed/0xf0
? common_startup_64+0x13e/0x141
</TASK>
---[ end trace 0000000000000000 ]---
mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.
Mapping the entire structure isn't actually necessary, as we don't ever
need more than one entry header mapped at once.
Changes efi_mokvar_table_init() to only map each entry header, not the
entire table, when determining the table size. Since we're not mapping
any data past the variable name, it also changes the code to enforce
that each variable name is NUL terminated, rather than attempting to
verify it in place.
Cc: <stable@vger.kernel.org>
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit fe08b7d508 ]
Change calls to async regmap write functions to use the normal
blocking writes so that the cs35l56 driver can use spi_bus_lock() to
gain exclusive access to the SPI bus.
As this is part of a fix, it makes only the minimal change to swap the
functions to the blocking equivalents. There's no need to risk
reworking the buffer allocation logic that is now partially redundant.
The async writes are a 12-year-old workaround for inefficiency of
synchronous writes in the SPI subsystem. The SPI subsystem has since
been changed to avoid the overheads, so this workaround should not be
necessary.
The cs35l56 driver needs to use spi_bus_lock() prevent bus activity
while it is soft-resetting the cs35l56. But spi_bus_lock() is
incompatible with spi_async() calls, which will fail with -EBUSY.
Fixes: 8a731fd37f ("ASoC: cs35l56: Move utility functions to shared file")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20250225131843.113752-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit be6686b823 ]
The i.MX System Controller Management Interface firmware is only present
on Freescale i.MX SoCs. Hence add a dependency on ARCH_MXC, to prevent
asking the user about this driver when configuring a kernel without
Freescale i.MX platform support.
Fixes: 514b2262ad ("firmware: arm_scmi: Fix i.MX build dependency")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ab027c488f ]
'struct scmi_imx_misc_ctrl_set_in' has a zero length array in the end,
The sizeof will not count 'value[]', and hence Tx size will be smaller
than actual size for Tx,and SCMI firmware will flag this as protocol
error.
Fix this by enlarge the Tx size with 'num * sizeof(__le32)' to count in
the size of data.
Fixes: 61c9f03e22 ("firmware: arm_scmi: Add initial support for i.MX MISC protocol")
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Tested-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Jason Liu <jason.hui.liu@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Message-Id: <20250123063441.392555-1-peng.fan@oss.nxp.com>
(sudeep.holla: Commit rewording and replace hardcoded sizeof(__le32) value)
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ba69e0750b upstream.
UEFI 2.11 introduced EFI_MEMORY_HOT_PLUGGABLE to annotate system memory
regions that are 'cold plugged' at boot, i.e., hot pluggable memory that
is available from early boot, and described as system RAM by the
firmware.
Existing loaders and EFI applications running in the boot context will
happily use this memory for allocating data structures that cannot be
freed or moved at runtime, and this prevents the memory from being
unplugged. Going forward, the new EFI_MEMORY_HOT_PLUGGABLE attribute
should be tested, and memory annotated as such should be avoided for
such allocations.
In the EFI stub, there are a couple of occurrences where, instead of the
high-level AllocatePages() UEFI boot service, a low-level code sequence
is used that traverses the EFI memory map and carves out the requested
number of pages from a free region. This is needed, e.g., for allocating
as low as possible, or for allocating pages at random.
While AllocatePages() should presumably avoid special purpose memory and
cold plugged regions, this manual approach needs to incorporate this
logic itself, in order to prevent the kernel itself from ending up in a
hot unpluggable region, preventing it from being unplugged.
So add the EFI_MEMORY_HOTPLUGGABLE macro definition, and check for it
where appropriate.
Cc: stable@vger.kernel.org
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b628510397 upstream.
Commit 2e4955167e ("firmware: qcom: scm: Fix __scm and waitq
completion variable initialization") introduced a write barrier in probe
function to store global '__scm' variable. We all known barriers are
paired (see memory-barriers.txt: "Note that write barriers should
normally be paired with read or address-dependency barriers"), therefore
accessing it from concurrent contexts requires read barrier. Previous
commit added such barrier in qcom_scm_is_available(), so let's use that
directly.
Lack of this read barrier can result in fetching stale '__scm' variable
value, NULL, and dereferencing it.
Note that barrier in qcom_scm_is_available() satisfies here the control
dependency.
Fixes: ca61d6836e ("firmware: qcom: scm: fix a NULL-pointer dereference")
Fixes: 449d0d84bc ("firmware: qcom: scm: smc: switch to using the SCM allocator")
Cc: stable@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241209-qcom-scm-missing-barriers-and-all-sort-of-srap-v2-2-9061013c8d92@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0a744cceeb upstream.
Commit 2e4955167e ("firmware: qcom: scm: Fix __scm and waitq
completion variable initialization") introduced a write barrier in probe
function to store global '__scm' variable. It also claimed that it
added a read barrier, because as we all known barriers are paired (see
memory-barriers.txt: "Note that write barriers should normally be paired
with read or address-dependency barriers"), however it did not really
add it.
The offending commit used READ_ONCE() to access '__scm' global which is
not a barrier.
The barrier is needed so the store to '__scm' will be properly visible.
This is most likely not fatal in current driver design, because missing
read barrier would mean qcom_scm_is_available() callers will access old
value, NULL. Driver does not support unbinding and does not correctly
handle probe failures, thus there is no risk of stale or old pointer in
'__scm' variable.
However for code correctness, readability and to be sure that we did not
mess up something in this tricky topic of SMP barriers, add a read
barrier for accessing '__scm'. Change also comment from useless/obvious
what does barrier do, to what is expected: which other parts of the code
are involved here.
Fixes: 2e4955167e ("firmware: qcom: scm: Fix __scm and waitq completion variable initialization")
Cc: stable@vger.kernel.org
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241209-qcom-scm-missing-barriers-and-all-sort-of-srap-v2-1-9061013c8d92@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8ba14d9f49 upstream.
GCC 15 changed the default C standard version to C23, which should not
have impacted the kernel because it requests the gnu11 standard via
'-std=' in the main Makefile. However, the EFI libstub Makefile uses its
own set of KBUILD_CFLAGS for x86 without a '-std=' value (i.e., using
the default), resulting in errors from the kernel's definitions of bool,
true, and false in stddef.h, which are reserved keywords under C23.
./include/linux/stddef.h:11:9: error: expected identifier before ‘false’
11 | false = 0,
./include/linux/types.h:35:33: error: two or more data types in declaration specifiers
35 | typedef _Bool bool;
Set '-std=gnu11' in the x86 cflags to resolve the error and consistently
use the same C standard version for the entire kernel. All other
architectures reuse KBUILD_CFLAGS from the rest of the kernel, so this
issue is not visible for them.
Cc: stable@vger.kernel.org
Reported-by: Kostadin Shishmanov <kostadinshishmanov@protonmail.com>
Closes: https://lore.kernel.org/4OAhbllK7x4QJGpZjkYjtBYNLd_2whHx9oFiuZcGwtVR4hIzvduultkgfAIRZI3vQpZylu7Gl929HaYFRGeMEalWCpeMzCIIhLxxRhq4U-Y=@protonmail.com/
Reported-by: Jakub Jelinek <jakub@redhat.com>
Closes: https://lore.kernel.org/Z4467umXR2PZ0M1H@tucnak/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 19fdc68aa7 ]
A build with W=1 fails because there are code and data that are not
needed or used when CONFIG_EFI is not set. Move the "#ifdef CONFIG_EFI"
block to earlier in the source file so that the unused code/data are
not built.
drivers/firmware/efi/sysfb_efi.c:345:39: warning: ‘efifb_fwnode_ops’ defined but not used [-Wunused-const-variable=]
345 | static const struct fwnode_operations efifb_fwnode_ops = {
| ^~~~~~~~~~~~~~~~
drivers/firmware/efi/sysfb_efi.c:238:35: warning: ‘efifb_dmi_swap_width_height’ defined but not used [-Wunused-const-variable=]
238 | static const struct dmi_system_id efifb_dmi_swap_width_height[] __initconst = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/firmware/efi/sysfb_efi.c:188:35: warning: ‘efifb_dmi_system_table’ defined but not used [-Wunused-const-variable=]
188 | static const struct dmi_system_id efifb_dmi_system_table[] __initconst = {
| ^~~~~~~~~~~~~~~~~~~~~~
Fixes: 15d27b15de ("efi: sysfb_efi: fix build when EFI is not set")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202501071933.20nlmJJt-lkp@intel.com/
Cc: David Rheinsberg <david@readahead.eu>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: linux-fbdev@vger.kernel.org
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 1e76b546e6 ]
If SCM driver fails the probe, it should not leave global '__scm'
variable assigned, because external users of this driver will assume the
probe finished successfully. For example TZMEM parts ('__scm->mempool')
are initialized later in the probe, but users of it (__scm_smc_call())
rely on the '__scm' variable.
This fixes theoretical NULL pointer exception, triggered via introducing
probe deferral in SCM driver with call trace:
qcom_tzmem_alloc+0x70/0x1ac (P)
qcom_tzmem_alloc+0x64/0x1ac (L)
qcom_scm_assign_mem+0x78/0x194
qcom_rmtfs_mem_probe+0x2d4/0x38c
platform_probe+0x68/0xc8
Fixes: 40289e35ca ("firmware: qcom: scm: enable the TZ mem allocator")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241209-qcom-scm-missing-barriers-and-all-sort-of-srap-v2-4-9061013c8d92@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 0b2c29fb68 upstream.
For historical reasons, the legacy decompressor code on various
architectures supports 7 different compression types for the compressed
kernel image.
EFI zboot is not a compression library museum, and so the options can be
limited to what is likely to be useful in practice:
- GZIP is tried and tested, and is still one of the fastest at
decompression time, although the compression ratio is not very high;
moreover, Fedora is already shipping EFI zboot kernels for arm64 that
use GZIP, and QEMU implements direct support for it when booting a
kernel without firmware loaded;
- ZSTD has a very high compression ratio (although not the highest), and
is almost as fast as GZIP at decompression time.
Reducing the number of options makes it less of a hassle for other
consumers of the EFI zboot format (such as QEMU today, and kexec in the
future) to support it transparently without having to carry 7 different
decompression libraries.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 6fe437cfe2 ]
Currently, ffa_dev->properties is set after the ffa_device_register()
call return in ffa_setup_partitions(). This could potentially result in
a race where the partition's properties is accessed while probing
struct ffa_device before it is set.
Update the ffa_device_register() to receive ffa_partition_info so all
the data from the partition information received from the firmware can
be updated into the struct ffa_device before the calling device_register()
in ffa_device_register().
Fixes: e781858488 ("firmware: arm_ffa: Add initial FFA bus support for device enumeration")
Signed-off-by: Levi Yun <yeoreum.yun@arm.com>
Message-Id: <20241203143109.1030514-2-yeoreum.yun@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 514b2262ad ]
The newly added SCMI vendor driver references functions in the
protocol driver but needs a Kconfig dependency to ensure it can link,
essentially the Kconfig dependency needs to be reversed to match the
link time dependency:
| arm-linux-gnueabi-ld: sound/soc/fsl/fsl_mqs.o: in function `fsl_mqs_sm_write':
| fsl_mqs.c:(.text+0x1aa): undefined reference to `scmi_imx_misc_ctrl_set'
| arm-linux-gnueabi-ld: sound/soc/fsl/fsl_mqs.o: in function `fsl_mqs_sm_read':
| fsl_mqs.c:(.text+0x1ee): undefined reference to `scmi_imx_misc_ctrl_get'
This however only works after changing the dependency in the SND_SOC_FSL_MQS
driver as well, which uses 'select IMX_SCMI_MISC_DRV' to turn on a
driver it depends on. This is generally a bad idea, so the best solution
is to change that into a dependency.
To allow the ASoC driver to keep building with the SCMI support, this
needs to be an optional dependency that enforces the link-time
dependency if IMX_SCMI_MISC_DRV is a loadable module but not
depend on it if that is disabled.
Fixes: 61c9f03e22 ("firmware: arm_scmi: Add initial support for i.MX MISC protocol")
Fixes: 101c902359 ("ASoC: fsl_mqs: Support accessing registers by scmi interface")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Message-Id: <20241115230555.2435004-1-arnd@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 06d39d79cb upstream.
cmdline_ptr is an out parameter, which is not allocated by the function
itself, and likely points into the caller's stack.
cmdline refers to the pool allocation that should be freed when cleaning
up after a failure, so pass this instead to free_pool().
Fixes: 42c8ea3dca ("efi: libstub: Factor out EFI stub entrypoint ...")
Cc: <stable@vger.kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit e6d654e9f5 ]
A prior bugfix that fixes a signed/unsigned error causes
another signed unsigned error.
A situation where log_tbl->size is invalid can cause the
size passed to memblock_reserve to become negative.
log_size from the main event log is an unsigned int, and
the code reduces to the following
u64 value = (int)unsigned_value;
This results in sign extension, and the value sent to
memblock_reserve becomes effectively negative.
Fixes: be59d57f98 ("efi/tpm: Fix sanity check of unsigned tbl_size being less than zero")
Signed-off-by: Gregory Price <gourry@gourry.net>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit aacfa0ef24 ]
efi_convert_cmdline() always returns a size of at least 1 because it
counts the NUL terminator, so the "cmdline_size == 0" condition is never
satisfied.
Change it to check if the string starts with a NUL character to get the
intended behavior: to use CONFIG_CMDLINE when load_options_size == 0.
Fixes: 60f38de7a8 ("efi/libstub: Unify command line param parsing")
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
- Add GENPD_FLAG_DEV_NAME_FW flag to generate unique names
pmdomain providers:
- arm: Use FLAG_DEV_NAME_FW to ensure unique names
- imx93-blk-ctrl: Fix the remove path
arm_scmi/qcom-cpucp:
- Report duplicate OPPs as firmware bugs for arm_scmi
- Skip OPP duplicates for arm_scmi
- Mark the qcom-cpucp mailbox irq with IRQF_NO_SUSPEND flag
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAmc3I+wXHHVsZi5oYW5z
c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjCmsYw/+PphbBhA6Tu1SjSwpkxx0QNBr
isc0DSwRG+iVfnwpeBB9lS5yLNwltbe8goZAVZYcFUdrCPs+OX5HZimFklAAufFh
X/S5Ge3MyXwiRjwwyz04wMl8SF2W4P90cLC9w8hB85dJ0/lhgTLCbi//eHXHQKkq
hzsVpusO4t+wa2HoTjdq6rqlSKW2NdUyZxrCWLDWaXrbqnBL0yJRs1rn2034w/qi
RannE36bm8YUTBgyiayViEGWC73VUtxB07oSn8Qq9dYzwjIUqVpqoBBQiJL4VCFR
/147/40rcq7T7B8qp9/3S82EV9vX26VAa/gUDDosb/RoB9XbBtx04QPBaHPiVitf
6kjqn6vD+F+jap+u7i0Q4PMvdfmSUfVeqbEx5ED3rpAbzfBazgyO4e3JAGFZOvqj
M6YP8i6mSmTOUZbkuF1dwmD9DtuoySaWzTrwUFluu8VMykTo/F8GqkeZXPIKg9CO
H+OXq81+btVOwXZ/HFRQPNVXY8Q7gQIQAsLoAW8QqXxzFJ8ovYHs0voT4KPXeWzu
56dWATJ6uh6P+zjIbWDDsg9m/tXhH5CGoRpn33OkhIBYnsSnoTDF6h4mVGr4K6Zn
W+uPS+Xg6nbXxaZHomJG3dDSpRWUA1FNVwiLZbnbvEBi5aU7FwdZNc8MCV6h5DOw
zaOeRa1zHz8F2K4l8z0=
=pPcz
-----END PGP SIGNATURE-----
Merge tag 'pmdomain-v6.12-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm
Pull pmdomain fixes from Ulf Hansson:
"pmdomain core:
- Add GENPD_FLAG_DEV_NAME_FW flag to generate unique names
pmdomain providers:
- arm: Use FLAG_DEV_NAME_FW to ensure unique names
- imx93-blk-ctrl: Fix the remove path
arm_scmi/qcom-cpucp:
- Report duplicate OPPs as firmware bugs for arm_scmi
- Skip OPP duplicates for arm_scmi
- Mark the qcom-cpucp mailbox irq with IRQF_NO_SUSPEND flag"
* tag 'pmdomain-v6.12-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm:
mailbox: qcom-cpucp: Mark the irq with IRQF_NO_SUSPEND flag
firmware: arm_scmi: Report duplicate opps as firmware bugs
firmware: arm_scmi: Skip opp duplicates
pmdomain: imx93-blk-ctrl: correct remove path
pmdomain: arm: Use FLAG_DEV_NAME_FW to ensure unique names
pmdomain: core: Add GENPD_FLAG_DEV_NAME_FW flag
Duplicate opps reported by buggy SCP firmware currently show up
as warnings even though the only functional impact is that the
level/index remain inaccessible. Make it less scary for the end
user by using dev_info instead, along with FW_BUG tag.
Suggested-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Cc: stable@vger.kernel.org
Message-ID: <20241030125512.2884761-4-quic_sibis@quicinc.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Buggy firmware can reply with duplicated PERF opps descriptors.
Ensure that the bad duplicates reported by the platform firmware doesn't
get added to the opp-tables.
Reported-by: Johan Hovold <johan+linaro@kernel.org>
Closes: https://lore.kernel.org/lkml/ZoQjAWse2YxwyRJv@hovoldconsulting.com/
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Cc: stable@vger.kernel.org
Message-ID: <20241030125512.2884761-3-quic_sibis@quicinc.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
- Fix handling of SVE traps from userspace on preemptible kernels when
converting the saved floating point state into SVE state.
- Remove broken support for the SMCCCv1.3 "SVE discard hint"
optimisation.
- Disable SME support, as the current support code suffers from numerous
issues around signal delivery, ptrace access and context-switch which
can lead to user-visible corruption of the register state.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCgAuFiEEPxTL6PPUbjXGY88ct6xw3ITBYzQFAmcsr4EQHHdpbGxAa2Vy
bmVsLm9yZwAKCRC3rHDchMFjNPPiCACg3kva9wv7Rs1BQa+dJKiTQ7e5rcaEQ2dK
3v86vxvyl/UJIx/AmGS3ydKlmBwQYOHlBGHH7Iw3XphZK6YQCsgbvmTHiE7UoimZ
IgWod1HRh8RN5sPctkgS+fg9ebD/BPQ/RW6HPUp6ZBwb4hxmaYW236FGWppienOn
W1hO8gz64uXig+UCSjxdSDnOPhPwvrw05DVkAdMF2HFxUgAr96T+BD+Bpcco+r+k
0cqlaCzsRgf9OKGPeFxTrfO1t02CsVvjfzEQMaj0Jd0f+2XNFlrGsMEZw3PCoiXv
zizjflLoVTzc0AAZWdFJXUPlRshmRFJj/R2HuXvb1m9shqU3NieO
=Z7Ls
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"Here is a (hopefully) final round of arm64 fixes for 6.12 that address
some user-visible floating point register corruption. Both of the
Marks have been working on this for a couple of weeks and we've ended
up in a position where SVE is solid but SME still has enough pending
issues that the most pragmatic solution for the release and stable
backports is to disable the feature. Yes, it's a shame, but the
hardware is rare as hen's teeth at the moment and we're better off
getting back to a known good state before fixing it all properly.
We're also improving the selftests for 6.13 to help avoid merging
broken code in the future.
Anyway, the good news is that we're removing a lot more code than
we're adding.
Summary:
- Fix handling of SVE traps from userspace on preemptible kernels
when converting the saved floating point state into SVE state.
- Remove broken support for the SMCCCv1.3 "SVE discard hint"
optimisation.
- Disable SME support, as the current support code suffers from
numerous issues around signal delivery, ptrace access and
context-switch which can lead to user-visible corruption of the
register state"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: Kconfig: Make SME depend on BROKEN for now
arm64: smccc: Remove broken support for SMCCCv1.3 SVE discard hint
arm64/sve: Discard stale CPU state when handling SVE traps
SMCCCv1.3 added a hint bit which callers can set in an SMCCC function ID
(AKA "FID") to indicate that it is acceptable for the SMCCC
implementation to discard SVE and/or SME state over a specific SMCCC
call. The kernel support for using this hint is broken and SMCCC calls
may clobber the SVE and/or SME state of arbitrary tasks, though FPSIMD
state is unaffected.
The kernel support is intended to use the hint when there is no SVE or
SME state to save, and to do this it checks whether TIF_FOREIGN_FPSTATE
is set or TIF_SVE is clear in assembly code:
| ldr <flags>, [<current_task>, #TSK_TI_FLAGS]
| tbnz <flags>, #TIF_FOREIGN_FPSTATE, 1f // Any live FP state?
| tbnz <flags>, #TIF_SVE, 2f // Does that state include SVE?
|
| 1: orr <fid>, <fid>, ARM_SMCCC_1_3_SVE_HINT
| 2:
| << SMCCC call using FID >>
This is not safe as-is:
(1) SMCCC calls can be made in a preemptible context and preemption can
result in TIF_FOREIGN_FPSTATE being set or cleared at arbitrary
points in time. Thus checking for TIF_FOREIGN_FPSTATE provides no
guarantee.
(2) TIF_FOREIGN_FPSTATE only indicates that the live FP/SVE/SME state in
the CPU does not belong to the current task, and does not indicate
that clobbering this state is acceptable.
When the live CPU state is clobbered it is necessary to update
fpsimd_last_state.st to ensure that a subsequent context switch will
reload FP/SVE/SME state from memory rather than consuming the
clobbered state. This and the SMCCC call itself must happen in a
critical section with preemption disabled to avoid races.
(3) Live SVE/SME state can exist with TIF_SVE clear (e.g. with only
TIF_SME set), and checking TIF_SVE alone is insufficient.
Remove the broken support for the SMCCCv1.3 SVE saving hint. This is
effectively a revert of commits:
* cfa7ff959a ("arm64: smccc: Support SMCCC v1.3 SVE register saving hint")
* a7c3acca53 ("arm64: smccc: Save lr before calling __arm_smccc_sve_check()")
... leaving behind the ARM_SMCCC_VERSION_1_3 and ARM_SMCCC_1_3_SVE_HINT
definitions, since these are simply definitions from the SMCCC
specification, and the latter is used in KVM via ARM_SMCCC_CALL_HINTS.
If we want to bring this back in future, we'll probably want to handle
this logic in C where we can use all the usual FPSIMD/SVE/SME helper
functions, and that'll likely require some rework of the SMCCC code
and/or its callers.
Fixes: cfa7ff959a ("arm64: smccc: Support SMCCC v1.3 SVE register saving hint")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: stable@vger.kernel.org
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20241106160448.2712997-1-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Where the last set of fixes was mostly drivers, this time the devicetree
changes all come at once, targeting mostly the Rockchips, Qualcomm and
NXP platforms.
The Qualcomm bugfixes target the Snapdragon X Elite laptops, specifically
problems with PCIe and NVMe support to improve reliability, and a boot
regresion on msm8939. Also for Snapdragon platforms, there are a number
of correctness changes in the several platform specific device drivers,
but none of these are as impactful.
On the NXP i.MX platform, the fixes are all for 64-bit i.MX8 variants,
correcting individual entries in the devicetree that were incorrect and
causing the media, video, mmc and spi drivers to misbehave in minor
ways.
The Arm SCMI firmware driver gets fixes for a use-after-free bug and
for correctly parsing firmware information.
On the RISC-V side, there are three minor devicetree fixes for starfive
and sophgo, again addressing only minor mistakes. One device driver
patch fixes a problem with spurious interrupt handling.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmcpR7oACgkQYKtH/8kJ
Uic9dA/+NzeNald+ap++pYYmIx9FcV3q3aieN4j5NRgAwUS84bNXpARkDQAK8lx8
GFzH7VUe0YwKlh+70P73eaLqsRyYE37eUyvabwnxgO0QnI798MZfM5diDvAFm0LK
kQKnNLx0qojt6HQTN3PVfOn+rcp2J5dgUV+ZAG9TEM3YKA0MY/bABRqaZtIZzSxg
WwM+jqFh5+EugiioSlL6HCdAVk12wwEJkAInEEY1y/KaeQS9K8vzEOwk4FDeIf2a
3V+G7IVIBI4rbvrAs2ukW3OrRiGT+svINS5k7qkap13YZUUjENnJYGYNm6woTTyb
INpBowLKr1gJ1Aluk8AELvpa+aX1BY9rkxP+vTG0HrZVdrPcPToFUBQA4qZgpu/i
k0uWb20uN1b2Uor2XP2hcTxvzfKPlvnYHxLTMG89PxoVrMX+oEQoCrAP24YcSkPd
srV0aU54MUHANXEnNco0txdElK+8L7ZCyB19KpVnqqshohDpQ+zkX15Hw9uQLwEc
RbF99SrR9KFg3sY62Q7LgJOhQ3x6LjGhqPCjejIZ9DvEzndArKYnkkiJYdxxhqkB
WN1LB/PmnKPAAh1lJdej6SPhiwCCpEFG3IyS/H1/lv7CR94LVode1J4dYTJmcZaq
aownmb4W1zECgMGQS6YjhuAG1h7D0QtSmWBAuiC+H+T2QTRPtKI=
=9YYG
-----END PGP SIGNATURE-----
Merge tag 'arm-fixes-6.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC fixes from Arnd Bergmann:
"Where the last set of fixes was mostly drivers, this time the
devicetree changes all come at once, targeting mostly the Rockchips,
Qualcomm and NXP platforms.
The Qualcomm bugfixes target the Snapdragon X Elite laptops,
specifically problems with PCIe and NVMe support to improve
reliability, and a boot regresion on msm8939.
Also for Snapdragon platforms, there are a number of correctness
changes in the several platform specific device drivers, but none of
these are as impactful.
On the NXP i.MX platform, the fixes are all for 64-bit i.MX8 variants,
correcting individual entries in the devicetree that were incorrect
and causing the media, video, mmc and spi drivers to misbehave in
minor ways.
The Arm SCMI firmware driver gets fixes for a use-after-free bug and
for correctly parsing firmware information.
On the RISC-V side, there are three minor devicetree fixes for
starfive and sophgo, again addressing only minor mistakes. One device
driver patch fixes a problem with spurious interrupt handling"
* tag 'arm-fixes-6.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (63 commits)
firmware: arm_scmi: Use vendor string in max-rx-timeout-ms
dt-bindings: firmware: arm,scmi: Add missing vendor string
riscv: dts: Replace deprecated snps,nr-gpios property for snps,dw-apb-gpio-port devices
arm64: dts: rockchip: Correct GPIO polarity on brcm BT nodes
arm64: dts: rockchip: Drop invalid clock-names from es8388 codec nodes
ARM: dts: rockchip: Fix the realtek audio codec on rk3036-kylin
ARM: dts: rockchip: Fix the spi controller on rk3036
ARM: dts: rockchip: drop grf reference from rk3036 hdmi
ARM: dts: rockchip: fix rk3036 acodec node
arm64: dts: rockchip: remove orphaned pinctrl-names from pinephone pro
soc: qcom: pmic_glink: Handle GLINK intent allocation rejections
rpmsg: glink: Handle rejected intent request better
arm64: dts: qcom: x1e80100: fix PCIe5 interconnect
arm64: dts: qcom: x1e80100: fix PCIe4 interconnect
arm64: dts: qcom: x1e80100: Fix up BAR spaces
MAINTAINERS: invert Misc RISC-V SoC Support's pattern
soc: qcom: socinfo: fix revision check in qcom_socinfo_probe()
arm64: dts: qcom: x1e80100-qcp: fix nvme regulator boot glitch
arm64: dts: qcom: x1e80100-microsoft-romulus: fix nvme regulator boot glitch
arm64: dts: qcom: x1e80100-yoga-slim7x: fix nvme regulator boot glitch
...
The Qualcomm EDAC driver's configuration of interrupts is made optional,
to avoid violating security constriants on X Elite platform .
The SCM drivers' detection mechanism for the presence of SHM bridge in QTEE,
is corrected to handle the case where firmware successfully returns that
the interface isn't supported.
The GLINK driver and the PMIC GLINK interface is updated to handle
buffer allocation issues during initialization of the communication
channel.
Allocation error handling in the socinfo dirver is corrected, and then
the fix is corrected.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmck/kgVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FqV8QAMEYiZp4KnS6QkT4h47ET/dl3AiY
EIyUge41uXjJYO4rK2JpYWi2Y30CXXwb0MRuhfZyI47mU2xYqP30hLEliqZLQqU3
ulc4hmVyPeelRtpSX36UyZQWcaTcr0IyWnhnPSPoIr/WuyvFojBVucnAzHGFYHw6
0Wl0Uwg0vaoptAXnAxC671ggkbXeUuxR1sOMnVAzAL9sUgZMAjDHg+Yc/Oz0i7KZ
16OcOPFWhN+PegrIAPKx5J3X9PUsEoPqE83y3DdRVv62c58RU5tfhrhEIhmo3DVn
ruTbrf1vV6cE1iWfGQIxyVt0WJGnY/dZqQjQxinZF0U9dlJl5+ke9ZTsaRxF0s0J
wejMDOoqtRbNeotLxhQAp0KbPbcUHg8kkUrYMiTZLMh4eNIEBi4yLT8KhDT7IUgT
SEP6jK4z482xpaTrDf5hDmnIMSfAO9fC50QiUMc8eNGL84XYIJgcYfi+LAP7TSiV
wP6PI1moQcSvq034csy4AfHlsULxMdqzqh86N4DSdkoa/om2JRiYIXfTkZOteOEg
GR4gPYigdBV8X4jj4XDiRbk+hbf+bbc6qet0HKvBPjYcKyvpH+SEVMsuxzAO8ybP
RjP5pDrOSb7mLlx/q8RBUwyuVWk6gtDhL6tgvwfP+qu+dxTcHgRSqAi5BQfOWMvf
2K4QO3/0tYunyqaf
=H31v
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmcoyr0ACgkQYKtH/8kJ
UiebJA/+OwoABEZcspBT92CnlAaIgIITx0znuO9srUcaiNxOTrZH2+T6z+sKHvOV
bfhj0JZyK0Qk6sxU9PoczIXb2Xc42lemkZwL6TfDjQlOI10mvfTOgnIFPldG1RIp
FcFjI3Tb6SKqh9GxDm5qLdxFn8ZoGKTLtUpP3FuV6lQNpiS7jLJILSNFXbVVMnk/
U2HY76YQ8u2DPk5ZXmjrw49NRDvQ22ufwxJJctE0fvVyr+AUhTFBHH9h6fo3RxbC
4IMCmEfVLnJ+ye9CqB4ahkcbu4gwzzU0eRpMb7mZ2GhufuCjgfBYA4U2XZhdEv0w
9GenVlPr0Hs1dtpUBxvfNf0kJ2uyti4UGkW7gn8+m/sl73bMVIGPX72rxdk3vbir
yztmdl3Nya0Nh9fPJxwP4BT6JsMshsz0POzvIOqeRTUw9yKD+wIQg9a+cwWWqdlu
jNvBGprW7MS03uQWIWYTGkjqDsStZVJaFO//PHx+ZZ0eY/H2Lminf3GL2tsAYUtE
pIVsS4NUcCygEELb7cEbi+S9EMkgQZPd71VAex9bjKNquBs60fSU1GZr3oOuHluv
2XI2O+FPwdTH+yAXzqRlCj5Rczum0joa9q2lHW7hs/h7AKVSNCfzj+0YjDFIhu2E
BnS0nbwm5axYm7vsnfA4O4QkE6AtGlRpmVfiumLg/Vif8KsA3N8=
=2qZ7
-----END PGP SIGNATURE-----
Merge tag 'qcom-drivers-fixes-for-6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm driver fixes for v6.12
The Qualcomm EDAC driver's configuration of interrupts is made optional,
to avoid violating security constriants on X Elite platform .
The SCM drivers' detection mechanism for the presence of SHM bridge in QTEE,
is corrected to handle the case where firmware successfully returns that
the interface isn't supported.
The GLINK driver and the PMIC GLINK interface is updated to handle
buffer allocation issues during initialization of the communication
channel.
Allocation error handling in the socinfo dirver is corrected, and then
the fix is corrected.
* tag 'qcom-drivers-fixes-for-6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
soc: qcom: pmic_glink: Handle GLINK intent allocation rejections
rpmsg: glink: Handle rejected intent request better
soc: qcom: socinfo: fix revision check in qcom_socinfo_probe()
firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling
EDAC/qcom: Make irq configuration optional
firmware: qcom: scm: fix a NULL-pointer dereference
firmware: qcom: scm: suppress download mode error
soc: qcom: Add check devm_kasprintf() returned value
MAINTAINERS: Qualcomm SoC: Match reserved-memory bindings
Link: https://lore.kernel.org/r/20241101161455.746290-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- Fix handling of POR_EL0 during signal delivery so that pushing the
signal context doesn't fail based on the pkey configuration of the
interrupted context and align our user-visible behaviour with that of
x86.
- Fix a bogus pointer being passed to the CPU hotplug code from the
Arm SDEI driver.
- Re-enable software tag-based KASAN with GCC by using an alternative
implementation of '__no_sanitize_address'.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCgAuFiEEPxTL6PPUbjXGY88ct6xw3ITBYzQFAmcjr8wQHHdpbGxAa2Vy
bmVsLm9yZwAKCRC3rHDchMFjNL2DB/4tNl7feCA2V4fW/Eu3RzXrHTdJbZvTjLDl
JjeXPZr4WdGQQMgQ0DPZtpnmeBzd5nswx9WHG9VSsUxc5g+rzWxwvMnUeplDvEXo
Y/QMUq4JZN3eqDZWPs0mEN4fMI+QOihInErVHvFXaJLcbxYrU5BvfwExgfY53AjT
ZJEPmF291OL6V4UCWVWggk44BQaTBeWmc4itJcYm6z6mIgAgh84MZGK5M0e582ip
CRAImDiAPqLxRO9kzKcYthI3FDyyVi1HtiSL1CiNktOXMNz19qPelq1XAnDEyvBt
TEUitTLTwbUJ0nqi4u7ve09aebneAq8nsGucteYTrBU4U/PRjvQO
=LTB9
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"The important one is a change to the way in which we handle protection
keys around signal delivery so that we're more closely aligned with
the x86 behaviour, however there is also a revert of the previous fix
to disable software tag-based KASAN with GCC, since a workaround
materialised shortly afterwards.
I'd love to say we're done with 6.12, but we're aware of some
longstanding fpsimd register corruption issues that we're almost at
the bottom of resolving.
Summary:
- Fix handling of POR_EL0 during signal delivery so that pushing the
signal context doesn't fail based on the pkey configuration of the
interrupted context and align our user-visible behaviour with that
of x86.
- Fix a bogus pointer being passed to the CPU hotplug code from the
Arm SDEI driver.
- Re-enable software tag-based KASAN with GCC by using an alternative
implementation of '__no_sanitize_address'"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: signal: Improve POR_EL0 handling to avoid uaccess failures
firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()
Revert "kasan: Disable Software Tag-Based KASAN with GCC"
kasan: Fix Software Tag-Based KASAN with GCC
Couple of fixes to address slab-use-after-free in scmi_bus_notifier()
via scmi_dev->name and possible incorrect clear channel transport
operation on A2P channel if some sort of P2A only messages are initiated
on A2P channel(occurs when stress tested passing /dev/random to the
channel).
Apart from this, there are fixes to address missing "arm" prefix in the
recently added property max-rx-timeout-ms which was missed in the review
but was identified when further additions to the same binding were
getting reviewed.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmcjvPAACgkQAEG6vDF+
4pg2mA/9GejbeYklmQLUl4EoEjz305mdorg29CCilJ7SvUachV7T7Rv2I/W1GCmB
F1eEwQe+SZ2COOEoIzKKvmEi7z49Cqm5gJbVvm8RVoR4Mrl1kAR373ZoO8rCFYEc
DMThkSJcPOPG976mf5Fy9tbCpTOrHSBh46afqid09+0r1u2/5VzLqo3uBVsoclGB
j8OixOlGokjL4K8cUs9cXLEJ9CJOyTu+0Z5e9HLvh4xj5l5n4remrMl9XWYBWuCR
PWUAAxdDUlmyDbrWsmeIyed/E8m0i/+O6SOupteGNd7NLMSKBYAfFw2XSYxz1wj3
yuF5hWxyU5a3icF+r2pGS00m6M8GbGF1yiY0U6tu4EAqfZTHdfsFh3X2ix+uFi0m
NCg9LmRLtlyBfgpt+Tj+X9Gw9Xq8nNBkaaVV14iYl1K7My3+RxLis8yesc+vfWmh
aoMnYr7fLKHUb+gVg6C6Ge1DOSDA6rg+JLQR/UG8Q1nKuIa0Yu/rrWKGammsd4CR
VMg48qKGTzpknSEh99yHzlFqGABdAUvJhpGqXcpHt+b13fjG3YY72gjT+uoThrDo
IWe5JFAFypR4P7bdfNkIWOFAH7Um7M86lanCd+LXsZ94CtZeO0CfF4d/nCB89DI2
TPXb0E6UOdZitXhWpN2BO4S9yxPQGPIypIP/I3cThA6I762aOvc=
=jlhL
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmck6icACgkQYKtH/8kJ
UifMMw/7BRDD3WeczzKlXY0MbnufnrVD2C/317Mx7OawcaInXALqfniMTjUIs3X/
06Ix90y7deDsCnXx9BCvpyOTVYGpwD7rjwDfiwrD+6wDeLWLMSpb53VRlIFNT8tc
F7uu4onUYH699Z/XkGRAoyZKhARE3+2zhFPLU6qoTuE6n6ImD6DzrEQBFwhQbH+L
gCCyIXfsFg5ALmKxi8Tcy3DSMnJt/AkV8o1dioTcOhxcQMScTeDgNUnSjglizvcB
Hca+l7cNxRFod9Ux95PqRH2ny4tzwNN2omX/AHRAeaScgPkpfcsAWYlKRXfhdroy
cxwdVGGEp73QbO2e+hTg99lwUi2mIb5AjDrGAmNp9YZF/8rZQ2qIMIWhdg4ugneJ
H5iZSe3NOQYDdo4hpO5q1kXQQQbECBVimjpcV4+vlxD8OZ6AQoCNrPV0oC3atV9A
49yZq/RmMZMYJUmEIFjAgLx0HuDmH/QjlSVZbqBDiWpzpOf4fW8B+DaKqQOUlIpP
1+w2nBiWvtKCpG5g4rNfF+fvDv0H3EEWKUSREF8EIHQ1sAQiXcQToSDbKDkeJVOG
ty4NDAMMM2JCd0MoD9QWE9UCOAdZbHw0Ub3FCZ03GP1gDb+HTifwZSFDlQLY8MqZ
/89kptiwBdMd1Taclraw/lANThpgITaiqJe2Mubuz8LEvZslK7k=
=E7pD
-----END PGP SIGNATURE-----
Merge tag 'scmi-fixes-6.12-2' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into HEAD
Arm SCMI fixes for v6.12(part 2)
Couple of fixes to address slab-use-after-free in scmi_bus_notifier()
via scmi_dev->name and possible incorrect clear channel transport
operation on A2P channel if some sort of P2A only messages are initiated
on A2P channel(occurs when stress tested passing /dev/random to the
channel).
Apart from this, there are fixes to address missing "arm" prefix in the
recently added property max-rx-timeout-ms which was missed in the review
but was identified when further additions to the same binding were
getting reviewed.
* tag 'scmi-fixes-6.12-2' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Use vendor string in max-rx-timeout-ms
dt-bindings: firmware: arm,scmi: Add missing vendor string
firmware: arm_scmi: Reject clear channel request on A2P
firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()
Link: https://lore.kernel.org/r/20241031172734.3109140-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
StarFive:
Two minor dts fixes, one setting the correct eth phy delay parameters
and one disabling unused nodes that caused warnings at probe time.
Firmware:
Fix the poll_complete() implementation in the auto-update driver so that
it behaves as the framework expects.
Misc:
Update the maintainer pattern for my dts entry, so that it covers
the specific platforms listed , rather than including all riscv
platforms with the list platforms excluded.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZyN2FAAKCRB4tDGHoIJi
0khPAQDfBrVD0CD25qS+GCQT1+OOodRlmZ8pUcLy5SiN/he9AAD/bpR4Y7esU+Ne
LTnsqL3OPXtVkA247UtKkw03K1ctKgI=
=LvhU
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmck6gcACgkQYKtH/8kJ
Uif9CRAAvtFa5tNJkpmSaIQlcC6rzi9oIyXCOuCaXAgWgFP+KiGTWgXp4l1eD52R
VkUGj+kBuZbozx2RPZCnH0W4aglkSPUzNtjFGOKvudTRrGGkDfJpGS+r3hIHb5B7
wOxZ/RpniQBtlhxxKEYIoC22Rv71p6qXfXBny/Add6Uy+TRh7w/+SvBOfXqWQEmn
3afc+uwYagxbA6ffe9odT6DtKXE97PynbhaDN7bfkXSDE/HyBvIytxrCEXTH+KAU
8bb8bwu2puLNpDGFJo+gC6p0cMAq/8FTamibNJ68sr22DDn7Jq7ugub7sumlUHMv
cS7+1Lo8ubpNPZzs9pXR+SknRkLpwXuTYDfyHJJh0BJxbLYTuU5HphGvFpu4/j3E
jF5GP7S4VvVbOqGk0dSidegrf3wF8FMxk0migA2kx5DY7gwc3FIL6VTeiQEZFE36
37cjs2lt9L7OyB+gPoSZjcoqNaSvd+ommWlXCcLRRSBMyPfMJ49nv7WRhdpkXNtA
PrrT9ESQ+/vIjjsB1qfVH6SFMZCFwBHNN3jnsg0OawGxIvS+ko8PmNli5eTULWp+
Jp9Ds/aMjQAzH50Ez2YQi6ysV3otjA8P2YQ1uN+DDdNe+oz+00kSw7N1whGo74lk
b/EpoeeDUvTsOu2ibJne+SOzGZ5VLW0M5df4hfzdDo/oVx131As=
=SLzW
-----END PGP SIGNATURE-----
Merge tag 'riscv-soc-fixes-for-v6.12-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into HEAD
RISC-V soc fixes for v6.12-rc6
StarFive:
Two minor dts fixes, one setting the correct eth phy delay parameters
and one disabling unused nodes that caused warnings at probe time.
Firmware:
Fix the poll_complete() implementation in the auto-update driver so that
it behaves as the framework expects.
Misc:
Update the maintainer pattern for my dts entry, so that it covers
the specific platforms listed , rather than including all riscv
platforms with the list platforms excluded.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
* tag 'riscv-soc-fixes-for-v6.12-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
MAINTAINERS: invert Misc RISC-V SoC Support's pattern
riscv: dts: starfive: Update ethernet phy0 delay parameter values for Star64
riscv: dts: starfive: disable unused csi/camss nodes
firmware: microchip: auto-update: fix poll_complete() to not report spurious timeout errors
Link: https://lore.kernel.org/r/20241031-colossal-cassette-617817c9bec3@spud
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The original optional property was missing a vendor string prefix; this
has been rectified.
Fix the naming of such optional property in code too.
Cc: Peng Fan <peng.fan@nxp.com>
Fixes: 1780e411ef ("firmware: arm_scmi: Use max-rx-timeout-ms from devicetree")
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Message-Id: <20241028120151.1301177-8-cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
In sdei_device_freeze(), the input parameter of cpuhp_remove_state() is
passed as 'sdei_entry_point' by mistake. Change it to 'sdei_hp_state'.
Fixes: d2c48b2387 ("firmware: arm_sdei: Fix sleep from invalid context BUG")
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20241016084740.183353-1-wangxiongfeng2@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
When enabling SHM bridge, QTEE returns 0 and sets error 4 in result to
qcom_scm for unsupported platforms. Currently, tzmem interprets this as
an unknown error rather than recognizing it as an unsupported platform.
Error log:
[ 0.177224] qcom_scm firmware:scm: error (____ptrval____): Failed to enable the TrustZone memory allocator
[ 0.177244] qcom_scm firmware:scm: probe with driver qcom_scm failed with error 4
To address this, modify the function call qcom_scm_shm_bridge_enable()
to remap result to indicate an unsupported error. This way, tzmem will
correctly identify it as an unsupported platform case instead of
reporting it as an error.
Fixes: 178e19c0df ("firmware: qcom: scm: add support for SHM bridge operations")
Signed-off-by: Qingqing Zhou <quic_qqzhou@quicinc.com>
Co-developed-by: Kuldeep Singh <quic_kuldsing@quicinc.com>
Signed-off-by: Kuldeep Singh <quic_kuldsing@quicinc.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com>
Link: https://lore.kernel.org/r/20241022192148.1626633-1-quic_kuldsing@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The clear channel transport operation is supposed to be called exclusively
on the P2A channel from the agent, since it relinquishes the ownership of
the channel to the platform, after this latter has initiated some sort of
P2A communication.
Make sure that, if it is ever called on a A2P, is logged and ignored.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Message-Id: <20241021171544.2579551-1-cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
fw_upload's poll_complete() is really intended for use with
asynchronous write() implementations - or at least those where the
write() loop may terminate without the kernel yet being aware of whether
or not the firmware upload has succeeded. For auto-update, write() is
only ever called once and will only return when uploading has completed,
be that by passing or failing. The core fw_upload code only calls
poll_complete() after the final call to write() has returned.
However, the poll_complete() implementation in the auto-update driver
was written to expect poll_complete() to be called from another context,
and it waits for a completion signalled from write(). Since
poll_complete() is actually called from the same context, after the
write() loop has terminated, wait_for_completion() never sees the
completion get signalled and always times out, causing programming to
always report a failing.
Since write() is full synchronous, and its return value will indicate
whether or not programming passed or failed, poll_complete() serves no
purpose and can be cut down to simply return FW_UPLOAD_ERR_NONE.
Cc: stable@vger.kernel.org
Fixes: ec5b0f1193 ("firmware: microchip: add PolarFire SoC Auto Update support")
Reported-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Tested-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Couple of fixes to address the issues found and reported on Broadcom
STB platforms following the recent refactor of all the SCMI transports
as standalone drivers.
One of the issue is that the effective timeout value is much less than
the intended value due to the way mailbox messages are queues in the
mailbox framework. Since we block or serialise the shmem access anyway,
there is no point in utilizing mailbox queues. The issue is fixed with
exclusive lock on the channel when sending the message.
The other issues is actually non-issue for upstream, but the workaround
is just changing the link order of the transport drivers which enables
Broadcom STB platforms to run both upstream and custom downstream kernel
without any device tree changes. So pushing this to help them test upstream
seamlessly as it has no practical or theoretical impact for others.
There is also a fix to address possible double freeing of the name string
in scmi_debugfs_common_cleanup() when devm_add_action_or_reset() fails.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmcOalcACgkQAEG6vDF+
4pj9LhAAmTLLEGbDAWSGsU/WTGGTcYexmFnDHmHWTNeY435P1wF44aTabA+9ZVBk
LZSQWNpduuSyAeQwxCUq3FuPtq2DhHSMZT55fzG4Cbt3+2ujNMHX7dUJC4aEU3U5
1P6PrAhSfvCzUKzF6KVtO0mlBx5+Ar8hayR2owewQpX7hlQV4yzM6lhYvByiRrII
LeVD5mmreBe8k4PfUMsLyaY0Bms005HStcbB1ArVkRe5hr3IQ99FQ4Zhp06qqLLY
+iqHLSZekGW0HUbtZVYAxJ8IOtgA88iI8B+7TF5iq7/UqxNGzRdSSeI6lrxZk9Qr
OmcjrTfp+aohQOj0Fep+hLBj2rAdzAmnLIZMa4seLdY5tgZtoz7schDeqW2We2Uu
WELpLgwXzrxeTn/CGXVKGVbB6eunAY0Hjf7NLnqmQe7x/Wt5cRkqpmPJhbMZKu75
iE5nk1CooaN7tBhrZUhqnEFtlN627V/tdqc8klVqnfArz99JA9Ec9ixdopp33sji
QXFwM/xe/GfhZE/3+YdvRb0fGVvoWhU+2JvSKmGax4jWQpWSpVR/mD/BwMEH5lDn
8xTG/Bd/J71sHoPAhORdJVVDexNOoNoPIDBi6J5h4DzEvD5juFo5+TnWrXvzxGFy
OH8H2Ic2qRTc290qO9oqwyRXZVPmd/46nEzn2oMeil3qvVdrAw0=
=NahH
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmcO0w8ACgkQYKtH/8kJ
Uif23w//SLRjEL/ZLhH1NuovqXPgvb8fsibMMQRTfyitCBwsxbhYvdy0gGwtZCTq
5eSbXx2O+GOZSRUaDWoEPIJAIuzR5ASjrgUWzjqEVy8diY9X5GO9mbiqByyQnsp3
GJxiemODqhvbvnFBdcedZIn2eUyPapTAAdj9+CCCcxdd71czxbJOb8ek4pVFN3OO
fj+iKm6mT7qW7MM/tYsebgP/4oVcA+4Sz+XMjToyJ29vXoA31tWcrumnrMcRGLcy
s685Nv8mhDw9ZsMhNbTghSACBslzxo2oQoKSkd0MiP7LmMxbDj9Nx4U+KxAlbR4f
4ZOzfBVkLv/oGwYG+sVAYJEkh2M0V9EurlECTnLg9taq1/bGCEyFjqAZ15EaCRLS
T5VcDaXspiYR3glEWc2Ccbjbw3TD9PTUqBYsS8/jSLj6XKtrw1CnGQe5F3i9HCPL
gLoHtX5T0fM2qu35ADQT7Xx49nXY+IXLvZBVqiy1lcjhPRrNyV8UYi0xGoTPcu0D
6rukL3VREmrNOJ1kuFc+T6KgWzxPMHwP6Ojiq6+UwiAdlDFOc323RuOeStVjVs34
G5bUNhVKWxCIH29NSR7/ckvLNCDh2DLkfwXuTz4P+foi9dEf2EMRuBSKueAF9ywO
IoBJhwCb5o7WfyX5jdGT0UluNvnMjLA9i4qAjLWc7ZDO1PQsjqE=
=iRE2
-----END PGP SIGNATURE-----
Merge tag 'scmi-fixes-6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Arm SCMI fixes for v6.12
Couple of fixes to address the issues found and reported on Broadcom
STB platforms following the recent refactor of all the SCMI transports
as standalone drivers.
One of the issue is that the effective timeout value is much less than
the intended value due to the way mailbox messages are queues in the
mailbox framework. Since we block or serialise the shmem access anyway,
there is no point in utilizing mailbox queues. The issue is fixed with
exclusive lock on the channel when sending the message.
The other issues is actually non-issue for upstream, but the workaround
is just changing the link order of the transport drivers which enables
Broadcom STB platforms to run both upstream and custom downstream kernel
without any device tree changes. So pushing this to help them test upstream
seamlessly as it has no practical or theoretical impact for others.
There is also a fix to address possible double freeing of the name string
in scmi_debugfs_common_cleanup() when devm_add_action_or_reset() fails.
* tag 'scmi-fixes-6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Queue in scmi layer for mailbox implementation
firmware: arm_scmi: Give SMC transport precedence over mailbox
firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup()
Link: https://lore.kernel.org/r/20241015185128.1000604-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Couple of fixes to avoid string-fortify warnings in export_uuid()
and memcpy() from the recently added functions to support
FFA_MSG_SEND_DIRECT_REQ2 and FFA_MSG_SEND_DIRECT_RESP2.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmcObT8ACgkQAEG6vDF+
4phYqw/+IrqZZEx0U3KDutI4bvLVDlkZ79+Nn1AprdYroXUGOJxA7eHi9rs3SWDO
3QUuz5XFfZB3QR2t6lhdGTdweZbgZTr4dOUTu21FvHgvVFm2LlN//R/8MdaxZc+k
a8su9g4wQKyclSD83niXciTo5dlq6LPlAtO40aojawxghbuWX+EhRvwI+iNcOiKq
HEfdQT8AdHp+MXJGll4IWvDxo7SLX5MzYJV/lEG/3eApYkILlW1AZFRLnX3m/pjj
PlY5T/hg69Ap3sy+fVoH9bo7HFRz8C/cqa3nT09MbGFPLN5jH+YYSMsOTBo1zeL7
wteHtxYhc79TjaE6TzGtcYXNwdRRg0J38jkVlk00jdrBzPmjtqqo0tdooDtuOjAF
0qd2Xw6XFnmQmmBl6M2oz3ASMV7ltecl9cd9+ULvBCLgVEd40kAKqxzXzQra+zdU
vlOxHscodyiv2wC0UFDYQG7CbWoLjBvTew/4zXo6Hc7JKigmrYJrKUDb7b3JvzBj
3wWyMIEBYuvXrzIl9ZeSXEF/IEVIdKA4AvLWLLemgH2CyUHRPRzefccgT0qDu2hJ
56hd8zxvE462wPz3lvJ9AF/uGyKF3xE+eFCJJeOxzR70ncTB03cPmednkjt4BVWY
Zp1jxmvCDs6KwxBIIa4MhDrlrU9KL4U63X4RSSpEmMIZhijaZSY=
=WC7N
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmcO0sQACgkQYKtH/8kJ
Uidr0BAArmJWCXkyGWFmXYfS0egXLMrN5kZ8yWagBE4sMGSCYaLG18pg9rsM08y8
dL6wPKH/BnSYVfeghn5WoEHYnEgDfV9/gpy8VJZBKEgFgdQSMzp5vbGhTpunofJc
+OcbuVLTNUIVmRcLLbkEvL+1SHXbMJhMYgxEdfCYZFTkk/zADZoUpHlWVLWH2au6
73makht41DX7Z2hegwGiUnQOJ31Kiwg0i7grPEgLKgs/A0BqaAZ/nAeLWVbfl5Vo
1xqXjQIm7J+kNXUtQEvom+US892vDuUAtVE4ZTTHHuA+hPLCk3nw9kuN+fjhsXv7
bvWH5zGaKZemHEWzwu7D2eqq17fS50KAv/5d9I6HU8o/xSAEpwNLe9NAysOMKfLV
6Y2WFa75cPZfy+W7wx0+Fdpa2vF4JFSrWd8y8ukxJIqerK1NYpp7fZBQyRFuSkOZ
ol3pLkN3fNMSqVAVl47BLfpm5YE5XfkGgvfdGqwC5CxclikXFuJkQAeA/X6+QqM9
MqHHAs3/PxVrFtjBL7R72CCjtuEJPZ8XNkDCHXEVcvK+O5J7tSNrj7Gqooi8vkj5
/K6Z8verV/K1uu2uZfI54MxMuuBSbcQ/pb0P55O6KsAeEato4oKL9atfItGR6n7+
X73QKZTlBZF3MhPRaw8wUXNeY6gNbI2CIlLM7oH9jNoIxkjpeV8=
=rApe
-----END PGP SIGNATURE-----
Merge tag 'ffa-fixes-6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Arm FF-A fixes for v6.12
Couple of fixes to avoid string-fortify warnings in export_uuid()
and memcpy() from the recently added functions to support
FFA_MSG_SEND_DIRECT_REQ2 and FFA_MSG_SEND_DIRECT_RESP2.
* tag 'ffa-fixes-6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_ffa: Avoid string-fortify warning caused by memcpy()
firmware: arm_ffa: Avoid string-fortify warning in export_uuid()
Link: https://lore.kernel.org/r/20241015185037.1000435-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Copying from a 144 byte structure arm_smccc_1_2_regs at an offset of 32
into an 112 byte struct ffa_send_direct_data2 causes a compile-time warning:
| In file included from drivers/firmware/arm_ffa/driver.c:25:
| In function 'fortify_memcpy_chk',
| inlined from 'ffa_msg_send_direct_req2' at drivers/firmware/arm_ffa/driver.c:504:3:
| include/linux/fortify-string.h:580:4: warning: call to '__read_overflow2_field'
| declared with 'warning' attribute: detected read beyond size of field
| (2nd parameter); maybe use struct_group()? [-Wattribute-warning]
| __read_overflow2_field(q_size_field, size);
Fix it by not passing a plain buffer to memcpy() to avoid the overflow
warning.
Fixes: aaef3bc981 ("firmware: arm_ffa: Add support for FFA_MSG_SEND_DIRECT_{REQ,RESP}2")
Signed-off-by: Gavin Shan <gshan@redhat.com>
Message-Id: <20241014004724.991353-1-gshan@redhat.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
send_message() does not block in the MBOX implementation. This is
because the mailbox layer has its own queue. However, this confuses
the per xfer timeouts as they all start their timeout ticks in
parallel.
Consider a case where the xfer timeout is 30ms and a SCMI transaction
takes 25ms:
| 0ms: Message #0 is queued in mailbox layer and sent out, then sits
| at scmi_wait_for_message_response() with a timeout of 30ms
| 1ms: Message #1 is queued in mailbox layer but not sent out yet.
| Since send_message() doesn't block, it also sits at
| scmi_wait_for_message_response() with a timeout of 30ms
| ...
| 25ms: Message #0 is completed, txdone is called and message #1 is sent
| 31ms: Message #1 times out since the count started at 1ms. Even though
| it has only been inflight for 6ms.
Fixes: 5c8a47a5a9 ("firmware: arm_scmi: Make scmi core independent of the transport type")
Signed-off-by: Justin Chen <justin.chen@broadcom.com>
Message-Id: <20241014160717.1678953-1-justin.chen@broadcom.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Copying to a 16 byte structure into an 8-byte struct member
causes a compile-time warning:
| In file included from drivers/firmware/arm_ffa/driver.c:25:
| In function 'fortify_memcpy_chk',
| inlined from 'export_uuid' at include/linux/uuid.h:88:2,
| inlined from 'ffa_msg_send_direct_req2' at drivers/firmware/arm_ffa/driver.c:488:2:
| include/linux/fortify-string.h:571:25: error: call to '__write_overflow_field'
| declared with attribute warning: detected write beyond size of field
| (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
| __write_overflow_field(p_size_field, size);
Use a union for the conversion instead and make sure the byte order
is fixed in the process.
Fixes: aaef3bc981 ("firmware: arm_ffa: Add support for FFA_MSG_SEND_DIRECT_{REQ,RESP}2")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Message-Id: <20240909110938.247976-1-arnd@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Broadcom STB platforms have for historical reasons included both
"arm,scmi-smc" and "arm,scmi" in their SCMI Device Tree node compatible
string, in that order.
After the commit b53515fa17 ("firmware: arm_scmi: Make MBOX transport
a standalone driver") and with a kernel configuration that enables both
the SMC and the mailbox transports, we would probe the mailbox transport,
but fail to complete since we would not have a mailbox driver available.
With each SCMI transport being a platform driver with its own set of
compatible strings to match, rather than an unique platform driver entry
point, we no longer match from most specific to least specific. There is
also no simple way for the mailbox driver to return -ENODEV and let
another platform driver attempt probing. This leads to a platform with
no SCMI provider, therefore all drivers depending upon SCMI resources
are put on deferred probe forever.
By keeping the SMC transport objects linked first, we can let the
platform driver match the compatible string and probe successfully with
no adverse effects on platforms using the mailbox transport.
This is just the workaround to the issue observed which doesn't have any
impact on the other platforms.
Fixes: b53515fa17 ("firmware: arm_scmi: Make MBOX transport a standalone driver")
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Message-Id: <20241007235413.507860-1-florian.fainelli@broadcom.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
