user/sven/linux.git/drivers/firmware, branch v6.6.92

firmware: arm_scmi: Fix timeout checks on polling path

2025-05-22T12:12:13Z

[ Upstream commit c23c03bf1faa1e76be1eba35bad6da6a2a7c95ee ] Polling mode transactions wait for a reply busy-looping without holding a spinlock, but currently the timeout checks are based only on elapsed time: as a result we could hit a false positive whenever our busy-looping thread is pre-empted and scheduled out for a time greater than the polling timeout. Change the checks at the end of the busy-loop to make sure that the polling wasn't indeed successful or an out-of-order reply caused the polling to be forcibly terminated. Fixes: 31d2f803c19c ("firmware: arm_scmi: Add sync_cmds_completed_on_ret transport flag") Reported-by: Huangjie Closes: https://lore.kernel.org/arm-scmi/20250123083323.2363749-1-jackhuang021@gmail.com/ Signed-off-by: Cristian Marussi Cc: stable@vger.kernel.org # 5.18.x Message-Id: <20250310175800.1444293-1-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_scmi: Track basic SCMI communication debug metrics

2025-05-22T12:12:13Z

[ Upstream commit 0b3d48c4726e1b20dffd2ff81a9d94d5d930220b ] Add the support for counting some of the SCMI communication debug metrics like how many were sent successfully or with some errors, responses received, notifications and delayed responses, transfer timeouts and errors from the firmware/platform. In many cases, the traces exists. But the traces are not always necessarily enabled and getting such cumulative SCMI communication debug metrics helps in understanding if there are any possible improvements that can be made on either side of SCMI communication. Signed-off-by: Luke Parkin Reviewed-by: Cristian Marussi Tested-by: Cristian Marussi Message-Id: <20240805131013.587016-4-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla Stable-dep-of: c23c03bf1faa ("firmware: arm_scmi: Fix timeout checks on polling path") Signed-off-by: Sasha Levin

firmware: arm_scmi: Add support for debug metrics at the interface

2025-05-22T12:12:13Z

[ Upstream commit 1b18d4295f9d1125bc7a799fc12924cd45fc04b1 ] Since SCMI involves interaction with the entity(software, firmware and/or hardware) providing services or features, it is quite useful to track certain metrics(for pure debugging purposes) like how many messages were sent or received, were there any failures, what kind of failures, ..etc. Add a new optional config option for the above purpose and the initial support for counting such key debug metrics. Signed-off-by: Luke Parkin Reviewed-by: Cristian Marussi Tested-by: Cristian Marussi Message-Id: <20240805131013.587016-3-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla Stable-dep-of: c23c03bf1faa ("firmware: arm_scmi: Fix timeout checks on polling path") Signed-off-by: Sasha Levin

firmware: arm_scmi: Add message dump traces for bad and unexpected replies

2025-05-22T12:12:13Z

[ Upstream commit 5076ab66db1671a5cd9ecfb857d1949e36a33142 ] It is useful to have message dump traces for any invalid/bad/unexpected replies. Let us add traces for the same as well as late-timed-out, out-of-order and unexpected/spurious messages. Signed-off-by: Cristian Marussi Link: https://lore.kernel.org/r/20240325204620.1437237-4-cristian.marussi@arm.com Signed-off-by: Sudeep Holla Stable-dep-of: c23c03bf1faa ("firmware: arm_scmi: Fix timeout checks on polling path") Signed-off-by: Sasha Levin

firmware: arm_scmi: Add helper to trace bad messages

2025-05-22T12:12:12Z

[ Upstream commit 5dc0e0b1f0ea2b55031f84a365962b9b45869b98 ] Upon reception of malformed and unexpected timed-out SCMI messages, it is not possible to trace those bad messages in their entirety, because usually we cannot even retrieve the payload, or it is just not reliable. Add a helper to trace at least the content of the header of the received message while associating a meaningful tag and error code. Signed-off-by: Cristian Marussi Link: https://lore.kernel.org/r/20240325204620.1437237-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla Stable-dep-of: c23c03bf1faa ("firmware: arm_scmi: Fix timeout checks on polling path") Signed-off-by: Sasha Levin

firmware: arm_ffa: Skip Rx buffer ownership release if not acquired

2025-05-09T07:44:04Z

[ Upstream commit 4567bdaaaaa1744da3d7da07d9aca2f941f5b4e5 ] Completion of the FFA_PARTITION_INFO_GET ABI transfers the ownership of the caller’s Rx buffer from the producer(typically partition mnager) to the consumer(this driver/OS). FFA_RX_RELEASE transfers the ownership from the consumer back to the producer. However, when we set the flag to just return the count of partitions deployed in the system corresponding to the specified UUID while invoking FFA_PARTITION_INFO_GET, the Rx buffer ownership shouldn't be transferred to this driver. We must be able to skip transferring back the ownership to the partition manager when we request just to get the count of the partitions as the buffers are not acquired in this case. Firmware may return FFA_RET_DENIED or other error for the ffa_rx_release() in such cases. Fixes: bb1be7498500 ("firmware: arm_ffa: Add v1.1 get_partition_info support") Message-Id: <20250321115700.3525197-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_scmi: Balance device refcount when destroying devices

2025-05-09T07:44:04Z

[ Upstream commit 9ca67840c0ddf3f39407339624cef824a4f27599 ] Using device_find_child() to lookup the proper SCMI device to destroy causes an unbalance in device refcount, since device_find_child() calls an implicit get_device(): this, in turns, inhibits the call of the provided release methods upon devices destruction. As a consequence, one of the structures that is not freed properly upon destruction is the internal struct device_private dev->p populated by the drivers subsystem core. KMemleak detects this situation since loading/unloding some SCMI driver causes related devices to be created/destroyed without calling any device_release method. unreferenced object 0xffff00000f583800 (size 512): comm "insmod", pid 227, jiffies 4294912190 hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6...... backtrace (crc 114e2eed): kmemleak_alloc+0xbc/0xd8 __kmalloc_cache_noprof+0x2dc/0x398 device_add+0x954/0x12d0 device_register+0x28/0x40 __scmi_device_create.part.0+0x1bc/0x380 scmi_device_create+0x2d0/0x390 scmi_create_protocol_devices+0x74/0xf8 scmi_device_request_notifier+0x1f8/0x2a8 notifier_call_chain+0x110/0x3b0 blocking_notifier_call_chain+0x70/0xb0 scmi_driver_register+0x350/0x7f0 0xffff80000a3b3038 do_one_initcall+0x12c/0x730 do_init_module+0x1dc/0x640 load_module+0x4b20/0x5b70 init_module_from_file+0xec/0x158 $ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0 device_add+0x954/0x12d0: kmalloc_noprof at include/linux/slab.h:901 (inlined by) kzalloc_noprof at include/linux/slab.h:1037 (inlined by) device_private_init at drivers/base/core.c:3510 (inlined by) device_add at drivers/base/core.c:3561 Balance device refcount by issuing a put_device() on devices found via device_find_child(). Reported-by: Alice Ryhl Closes: https://lore.kernel.org/linux-arm-kernel/Z8nK3uFkspy61yjP@arm.com/T/#mc1f73a0ea5e41014fa145147b7b839fc988ada8f CC: Sudeep Holla CC: Catalin Marinas Fixes: d4f9dddd21f3 ("firmware: arm_scmi: Add dynamic scmi devices creation") Signed-off-by: Cristian Marussi Tested-by: Alice Ryhl Message-Id: <20250306185447.2039336-1-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

efi/libstub: Bump up EFI_MMAP_NR_SLACK_SLOTS to 32

2025-04-25T08:45:55Z

commit ec4696925da6b9baec38345184403ce9e29a2e48 upstream. Recent platforms require more slack slots than the current value of EFI_MMAP_NR_SLACK_SLOTS, otherwise they fail to boot. The current workaround is to append `efi=disable_early_pci_dma` to the kernel's cmdline. So, bump up EFI_MMAP_NR_SLACK_SLOTS to 32 to allow those platforms to boot with the aforementioned workaround. Signed-off-by: Hamza Mahfooz Acked-by: Ard Biesheuvel Reviewed-by: Allen Pais Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman

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

2025-04-10T12:37:39Z

[ 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-28T20:59:55Z

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