linux-stable.git/drivers/firmware, branch linux-6.13.y

firmware: cs_dsp: Ensure cs_dsp_load[_coeff]() returns 0 on success

2025-04-10T12:41:57+00:00

[ Upstream commit 2593f7e0dc93a898a84220b3fb180d86f1ca8c60 ]

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 fe08b7d5085a ("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: fe08b7d5085a ("firmware: cs_dsp: Remove async regmap writes")
Signed-off-by: Richard Fitzgerald 
Link: https://patch.msgid.link/20250323170529.197205-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

efi/libstub: Avoid physical address 0x0 when doing random allocation

2025-03-28T21:04:56+00:00

commit cb16dfed0093217a68c0faa9394fa5823927e04c 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: 
Reported-by: Ben Schneider 
Tested-by: Ben Schneider 
Reviewed-by: Ilias Apalodimas 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

firmware: qcom: uefisecapp: fix efivars registration race

2025-03-28T21:04:56+00:00

commit da8d493a80993972c427002684d0742560f3be4a 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: 6612103ec35a ("firmware: qcom: qseecom: convert to using the TZ allocator")
Cc: stable@vger.kernel.org	# 6.11
Cc: Bartosz Golaszewski 
Signed-off-by: Johan Hovold 
Reviewed-by: Konrad Dybcio 
Reviewed-by: Maximilian Luz 
Reviewed-by: Bartosz Golaszewski 
Link: https://lore.kernel.org/r/20250120151000.13870-1-johan+linaro@kernel.org
Signed-off-by: Bjorn Andersson 
Signed-off-by: Greg Kroah-Hartman

firmware: imx-scu: fix OF node leak in .probe()

2025-03-28T21:04:50+00:00

[ Upstream commit fbf10b86f6057cf79300720da4ea4b77e6708b0d ]

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: f25a066d1a07 ("firmware: imx-scu: Support one TX and one RX")
Signed-off-by: Joe Hattori 
Signed-off-by: Shawn Guo 
Signed-off-by: Sasha Levin

firmware: qcom: scm: Fix error code in probe()

2025-03-28T21:04:50+00:00

[ Upstream commit 7f048b202333b967782a98aa21bb3354dc379bbf ]

Set the error code if devm_qcom_tzmem_pool_new() fails.  Don't return
success.

Fixes: 1e76b546e6fc ("firmware: qcom: scm: Cleanup global '__scm' on probe failures")
Signed-off-by: Dan Carpenter 
Reviewed-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/a0845467-4f83-4070-ab1e-ff7e6764609f@stanley.mountain
Signed-off-by: Bjorn Andersson 
Signed-off-by: Sasha Levin

iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()

2025-03-22T19:56:44+00:00

[ Upstream commit 07e0d99a2f701123ad3104c0f1a1e66bce74d6e5 ]

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 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Sasha Levin

efi: Don't map the entire mokvar table to determine its size

2025-03-07T17:27:15+00:00

commit 2b90e7ace79774a3540ce569e000388f8d22c9e0 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:
   
   ? __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
   
  ---[ 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: 
Signed-off-by: Peter Jones 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

firmware: cs_dsp: Remove async regmap writes

2025-03-07T17:26:59+00:00

[ Upstream commit fe08b7d5085a9774abc30c26d5aebc5b9cdd6091 ]

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: 8a731fd37f8b ("ASoC: cs35l56: Move utility functions to shared file")
Signed-off-by: Richard Fitzgerald 
Link: https://patch.msgid.link/20250225131843.113752-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

firmware: imx: IMX_SCMI_MISC_DRV should depend on ARCH_MXC

2025-02-27T12:34:17+00:00

[ Upstream commit be6686b823b30a69b1f71bde228ce042c78a1941 ]

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: 514b2262ade48a05 ("firmware: arm_scmi: Fix i.MX build dependency")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Fabio Estevam 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Sasha Levin

firmware: arm_scmi: imx: Correct tx size of scmi_imx_misc_ctrl_set

2025-02-27T12:34:16+00:00

[ Upstream commit ab027c488fc4a1fff0a5b712d4bdb2d2d324e8f8 ]

'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: 61c9f03e22fc ("firmware: arm_scmi: Add initial support for i.MX MISC protocol")
Reviewed-by: Jacky Bai 
Tested-by: Shengjiu Wang 
Acked-by: Jason Liu 
Signed-off-by: Peng Fan 
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 
Signed-off-by: Sasha Levin