summaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)AuthorFilesLines
2025-05-29firmware: arm_scmi: Relax duplicate name constraint across protocol idsSudeep Holla1-13/+6
[ Upstream commit 21ee965267bcbdd733be0f35344fa0f0226d7861 ] Currently in scmi_protocol_device_request(), no duplicate scmi device name is allowed across any protocol. However scmi_dev_match_id() first matches the protocol id and then the name. So, there is no strict requirement to keep this scmi device name unique across all the protocols. Relax the constraint on the duplicate name across the protocols and inhibit only within the same protocol id. Message-Id: <20250131141822.514342-1-sudeep.holla@arm.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-29firmware: xilinx: Dont send linux address to get fpga config get statusSiva Durga Prasad Paladugu1-5/+1
[ Upstream commit 5abc174016052caff1bcf4cedb159bd388411e98 ] Fpga get config status just returns status through ret_payload and there is no need to allocate local buf and send its address through SMC args. Moreover, the address that is being passed till now is linux virtual address and is incorrect. Corresponding modification has been done in the firmware to avoid using the address sent by linux. Signed-off-by: Siva Durga Prasad Paladugu <siva.durga.prasad.paladugu@amd.com> Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com> Link: https://lore.kernel.org/r/20250207054951.1650534-1-nava.kishore.manne@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-29firmware: arm_ffa: Handle the presence of host partition in the partition infoSudeep Holla1-0/+4
[ Upstream commit 2f622a8b0722d332a2a149794a3add47bc9bdcf3 ] Currently it is assumed that the firmware doesn't present the host partition in the list of partitions presented as part of the response to PARTITION_INFO_GET from the firmware. However, there are few platforms that prefer to present the same in the list of partitions. It is not manadatory but not restricted as well. So handle the same by making sure to check the presence of the host VM ID in the XArray partition information maintained/managed in the driver before attempting to add it. Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-7-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-29firmware: arm_ffa: Reject higher major version as incompatibleSudeep Holla1-0/+8
[ Upstream commit efff6a7f16b34fd902f342b58bd8bafc2d6f2fd1 ] When the firmware compatibility was handled previously in the commit 8e3f9da608f1 ("firmware: arm_ffa: Handle compatibility with different firmware versions"), we only addressed firmware versions that have higher minor versions compared to the driver version which is should be considered compatible unless the firmware returns NOT_SUPPORTED. However, if the firmware reports higher major version than the driver supported, we need to reject it. If the firmware can work in a compatible mode with the driver requested version, it must return the same major version as requested. Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-12-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-29firmware: arm_ffa: Set dma_mask for ffa devicesViresh Kumar1-0/+1
[ Upstream commit cc0aac7ca17e0ea3ca84b552fc79f3e86fd07f53 ] Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer lead to following warning: WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124 Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <e3dd8042ac680bd74b6580c25df855d092079c18.1737107520.git.viresh.kumar@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-18firmware: arm_scmi: Fix timeout checks on polling pathCristian Marussi1-5/+8
commit c23c03bf1faa1e76be1eba35bad6da6a2a7c95ee upstream. 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 <huangjie1663@phytium.com.cn> Closes: https://lore.kernel.org/arm-scmi/20250123083323.2363749-1-jackhuang021@gmail.com/ Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Cc: stable@vger.kernel.org # 5.18.x Message-Id: <20250310175800.1444293-1-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-09firmware: arm_ffa: Skip Rx buffer ownership release if not acquiredSudeep Holla1-1/+2
[ 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 <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-09firmware: arm_scmi: Balance device refcount when destroying devicesCristian Marussi1-0/+3
[ 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 <aliceryhl@google.com> Closes: https://lore.kernel.org/linux-arm-kernel/Z8nK3uFkspy61yjP@arm.com/T/#mc1f73a0ea5e41014fa145147b7b839fc988ada8f CC: Sudeep Holla <sudeep.holla@arm.com> CC: Catalin Marinas <catalin.marinas@arm.com> Fixes: d4f9dddd21f3 ("firmware: arm_scmi: Add dynamic scmi devices creation") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Alice Ryhl <aliceryhl@google.com> Message-Id: <20250306185447.2039336-1-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-09firmware: cs_dsp: tests: Depend on FW_CS_DSP rather then enabling itNico Pache1-4/+1
[ Upstream commit a0b887f6eb9a0d1be3c57d00b0f3ba8408d3018a ] FW_CS_DSP gets enabled if KUNIT is enabled. The test should rather depend on if the feature is enabled. Fix this by moving FW_CS_DSP to the depends on clause. Fixes: dd0b6b1f29b9 ("firmware: cs_dsp: Add KUnit testing of bin file download") Signed-off-by: Nico Pache <npache@redhat.com> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20250411123608.1676462-4-rf@opensource.cirrus.com Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-02firmware: stratix10-svc: Add of_platform_default_populate()Mahesh Rao1-3/+11
commit 4d239f447f96bd2cb646f89431e9db186c1ccfd4 upstream. Add of_platform_default_populate() to stratix10-svc driver as the firmware/svc node was moved out of soc. This fixes the failed probing of child drivers of svc node. Cc: stable@vger.kernel.org Fixes: 23c3ebed382a ("arm64: dts: socfpga: agilex: move firmware out of soc node") Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Xu Yilun <yilun.xu@intel.com> Signed-off-by: Mahesh Rao <mahesh.rao@intel.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org> Link: https://lore.kernel.org/r/20250326115446.36123-1-dinguyen@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-25firmware: cs_dsp: test_bin_error: Fix uninitialized data used as fw versionRichard Fitzgerald3-32/+2
[ Upstream commit 285b2c74cf9982e873ef82a2cb1328d9e9406f65 ] Call cs_dsp_mock_xm_header_get_fw_version() to get the firmware version from the dummy XM header data in cs_dsp_bin_err_test_common_init(). Make the same change to cs_dsp_bin_test_common_init() and remove the cs_dsp_mock_xm_header_get_fw_version_from_regmap() function. The code in cs_dsp_test_bin.c was correctly calling cs_dsp_mock_xm_header_get_fw_version_from_regmap() to fetch the fw version from a dummy header it wrote to XM registers. However in cs_dsp_test_bin_error.c the test doesn't stuff a dummy header into XM, it populates it the normal way using a wmfw file. It should have called cs_dsp_mock_xm_header_get_fw_version() to get the data from its blob buffer, but was calling cs_dsp_mock_xm_header_get_fw_version_from_regmap(). As nothing had been written to the registers this returned the value of uninitialized data. The only other use of cs_dsp_mock_xm_header_get_fw_version_from_regmap() was cs_dsp_test_bin.c, but it doesn't need to use it. It already has a blob buffer containing the dummy XM header so it can use cs_dsp_mock_xm_header_get_fw_version() to read from that. Fixes: cd8c058499b6 ("firmware: cs_dsp: Add KUnit testing of bin error cases") Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20250410132129.1312541-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-20firmware: cs_dsp: test_control_parse: null-terminate test stringsThomas Weißschuh1-32/+19
commit 42ae6e2559e63c2d4096b698cd47aaeb974436df upstream. The char pointers in 'struct cs_dsp_mock_coeff_def' are expected to point to C strings. They need to be terminated by a null byte. However the code does not allocate that trailing null byte and only works if by chance the allocation is followed by such a null byte. Refactor the repeated string allocation logic into a new helper which makes sure the terminating null is always present. It also makes the code more readable. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Fixes: 83baecd92e7c ("firmware: cs_dsp: Add KUnit testing of control parsing") Cc: stable@vger.kernel.org Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> Tested-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20250211-cs_dsp-kunit-strings-v1-1-d9bc2035d154@linutronix.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-10firmware: cs_dsp: Ensure cs_dsp_load[_coeff]() returns 0 on successRichard Fitzgerald1-0/+2
[ 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 <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>
2025-04-10firmware: arm_scmi: use ioread64() instead of ioread64_hi_lo()Arnd Bergmann1-10/+0
[ Upstream commit 3b8c56d8072750fd9625f03b92d8d6000c98628f ] The scmi_common_fastchannel_db_ring() function calls either ioread64() or ioread64_hi_lo() depending on whether it is compiler for 32-bit or 64-bit architectures. The same logic is used to define ioread64() itself in the linux/io-64-nonatomic-hi-lo.h header file, so the special case is not really needed. The behavior here should not change at all. Fixes: 6f9ea4dabd2d ("firmware: arm_scmi: Generalize the fast channel support") Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20250304144346.1025658-1-arnd@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10firmware: arm_ffa: Skip the first/partition ID when parsing vCPU listSudeep Holla1-1/+1
[ Upstream commit c67c2332f8c80b03990914dfb66950c8d2fb87d8 ] The FF-A notification id list received in response to the call FFA_NOTIFICATION_INFO_GET is encoded as: partition ID followed by 0 or more vCPU ID. The count includes all of them. Fix the issue by skipping the first/partition ID so that only the list of vCPU IDs are processed correctly for a given partition ID. The first/ partition ID is read before the start of the loop. Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Reported-by: Andrei Homescu <ahomescu@google.com> Message-Id: <20250223213909.1197786-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10firmware: arm_ffa: Explicitly cast return value from NOTIFICATION_INFO_GETSudeep Holla1-1/+1
[ Upstream commit 3e282f41585c4dd49b688bd6395fd6f21a57c9f7 ] The return value ret.a2 is of type unsigned long and FFA_RET_NO_DATA is a negative value. Since the return value from the firmware can be just 32-bit even on 64-bit systems as FFA specification mentions it as int32 error code in w0 register, explicitly casting to s32 ensures correct sign interpretation when comparing against a signed error code FFA_RET_NO_DATA. Without casting, comparison between unsigned long and a negative constant could lead to unintended results due to type promotions. Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Reported-by: Andrei Homescu <ahomescu@google.com> Message-Id: <20250221095633.506678-2-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10firmware: arm_ffa: Explicitly cast return value from FFA_VERSION before ↵Sudeep Holla1-1/+1
comparison [ Upstream commit cecf6a504137aa238d768ae440a1f6488cb2f436 ] The return value ver.a0 is unsigned long type and FFA_RET_NOT_SUPPORTED is a negative value. Since the return value from the firmware can be just 32-bit even on 64-bit systems as FFA specification mentions it as int32 error code in w0 register, explicitly casting to s32 ensures correct sign interpretation when comparing against a signed error code FFA_RET_NOT_SUPPORTED. Without casting, comparison between unsigned long and a negative constant could lead to unintended results due to type promotions. Fixes: 3bbfe9871005 ("firmware: arm_ffa: Add initial Arm FFA driver support") Reported-by: Andrei Homescu <ahomescu@google.com> Message-Id: <20250221095633.506678-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10firmware: arm_ffa: Unregister the FF-A devices when cleaning up the partitionsSudeep Holla2-4/+6
[ Upstream commit 46dcd68aaccac0812c12ec3f4e59c8963e2760ad ] Both the FF-A core and the bus were in a single module before the commit 18c250bd7ed0 ("firmware: arm_ffa: Split bus and driver into distinct modules"). The arm_ffa_bus_exit() takes care of unregistering all the FF-A devices. Now that there are 2 distinct modules, if the core driver is unloaded and reloaded, it will end up adding duplicate FF-A devices as the previously registered devices weren't unregistered when we cleaned up the modules. Fix the same by unregistering all the FF-A devices on the FF-A bus during the cleaning up of the partitions and hence the cleanup of the module. Fixes: 18c250bd7ed0 ("firmware: arm_ffa: Split bus and driver into distinct modules") Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-8-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10firmware: arm_ffa: Refactor addition of partition information into XArrayViresh Kumar1-25/+22
[ Upstream commit 3c3d6767466ea316869c9f2bdd976aec8ce44545 ] Move the common code handling addition of the FF-A partition information into the XArray as a new routine. No functional change. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Message-Id: <20250217-ffa_updates-v3-6-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Stable-dep-of: 46dcd68aacca ("firmware: arm_ffa: Unregister the FF-A devices when cleaning up the partitions") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-20Merge tag 'efi-fixes-for-v6.14-3' of ↵Linus Torvalds1-0/+4
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: "Here's a final batch of EFI fixes for v6.14. The efivarfs ones are fixes for changes that were made this cycle. James's fix is somewhat of a band-aid, but it was blessed by the VFS folks, who are working with James to come up with something better for the next cycle. - Avoid physical address 0x0 for random page allocations - Add correct lockdep annotation when traversing efivarfs on resume - Avoid NULL mount in kernel_file_open() when traversing efivarfs on resume" * tag 'efi-fixes-for-v6.14-3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efivarfs: fix NULL dereference on resume efivarfs: use I_MUTEX_CHILD nested lock to traverse variables on resume efi/libstub: Avoid physical address 0x0 when doing random allocation
2025-03-14Merge tag 'qcom-drivers-fixes-for-6.14' of ↵Arnd Bergmann2-11/+11
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes Qualcomm driver fixes for v6.14 Fixes a locking issue in the PDR implementation, which manifest itself as transaction timeouts during the startup procedure for some remoteprocs. A registration race is fixed in the custom efivars implementation, resolving reported NULL pointer dereferences. Error handling related to tzmem allocation is corrected, to ensure that the allocation error is propagated. Lastly a trivial merge mistake in pmic_glink is addressed. * tag 'qcom-drivers-fixes-for-6.14' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: soc: qcom: pdr: Fix the potential deadlock firmware: qcom: uefisecapp: fix efivars registration race firmware: qcom: scm: Fix error code in probe() soc: qcom: pmic_glink: Drop redundant pg assignment before taking lock Link: https://lore.kernel.org/r/20250311022509.1232678-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-03-14efi/libstub: Avoid physical address 0x0 when doing random allocationArd Biesheuvel1-0/+4
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>
2025-03-06Merge tag 'imx-fixes-6.14' of ↵Arnd Bergmann1-0/+1
https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 6.14: - A tqma8mpql board fix from Alexander Stein to correct vqmmc-supply for usdhc3 - A change from Joe Hattori to fix OF node leak in imx-scu driver probe - A soc-imx8m driver fix from Peng Fan unregister cpufreq and soc device in cleanup path - A couple of changes from Stefan Eichenberger to fix iMX6 Apalis poweroff and iMX8M verdin-dahlia sound-card descriptions * tag 'imx-fixes-6.14' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: arm64: dts: freescale: imx8mm-verdin-dahlia: add Microphone Jack to sound card arm64: dts: freescale: imx8mp-verdin-dahlia: add Microphone Jack to sound card soc: imx8m: Unregister cpufreq and soc dev in cleanup path ARM: dts: imx6qdl-apalis: Fix poweroff on Apalis iMX6 arm64: dts: freescale: tqma8mpql: Fix vqmmc-supply firmware: imx-scu: fix OF node leak in .probe() Link: https://lore.kernel.org/r/Z8A+rihFV4K3l8QR@dragon Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-02-28Merge tag 'efi-fixes-for-v6.14-2' of ↵Linus Torvalds3-32/+29
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: "Another couple of EFI fixes for v6.14. Only James's patch stands out, as it implements a workaround for odd behavior in fwupd in user space, which creates EFI variables by touching a file in efivarfs, clearing the immutable bit (which gets set automatically for $reasons) and then opening it again for writing, none of which is really necessary. The fwupd author and LVFS maintainer is already rolling out a fix for this on the fwupd side, and suggested that the workaround in this PR could be backed out again during the next cycle. (There is a semantic mismatch in efivarfs where some essential variable attributes are stored in the first 4 bytes of the file, and so zero length files cannot exist, as they cannot be written back to the underlying variable store. So now, they are dropped once the last reference is released.) Summary: - Fix CPER error record parsing bugs - Fix a couple of efivarfs issues that were introduced in the merge window - Fix an issue in the early remapping code of the MOKvar table" * tag 'efi-fixes-for-v6.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi/mokvar-table: Avoid repeated map/unmap of the same page efi: Don't map the entire mokvar table to determine its size efivarfs: allow creation of zero length files efivarfs: Defer PM notifier registration until .fill_super efi/cper: Fix cper_arm_ctx_info alignment efi/cper: Fix cper_ia_proc_ctx alignment
2025-02-27efi/mokvar-table: Avoid repeated map/unmap of the same pageArd Biesheuvel1-3/+15
Tweak the logic that traverses the MOKVAR UEFI configuration table to only unmap the entry header and map the next one if they don't live in the same physical page. Link: https://lore.kernel.org/all/8f085931-3e9d-4386-9209-1d6c95616327@uncooperative.org/ Tested-By: Peter Jones <pjones@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-02-27efi: Don't map the entire mokvar table to determine its sizePeter Jones1-28/+13
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>
2025-02-27Merge tag 'sound-6.14-rc5' of ↵Linus Torvalds1-18/+6
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of fixes. The only slightly large change is for ASoC Cirrus codec, but that's still in a normal range. All the rest are small device-specific fixes and should be fairly safe to take" * tag 'sound-6.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda/realtek: Fix microphone regression on ASUS N705UD ALSA: hda/realtek: Fix wrong mic setup for ASUS VivoBook 15 ASoC: cs35l56: Prevent races when soft-resetting using SPI control firmware: cs_dsp: Remove async regmap writes ASoC: Intel: sof_sdw: warn both sdw and pch dmic are used ASoC: SOF: Intel: don't check number of sdw links when set dmic_fixup ASoC: dapm-graph: set fill colour of turned on nodes ASoC: fsl: Rename stream name of SAI DAI driver ASoC: es8328: fix route from DAC to output ALSA: usb-audio: Re-add sample rate quirk for Pioneer DJM-900NXS2 ASoC: tas2764: Set the SDOUT polarity correctly ASoC: tas2764: Fix power control mask ALSA: usb-audio: Avoid dropping MIDI events at closing multiple ports ASoC: tas2770: Fix volume scale
2025-02-25firmware: cs_dsp: Remove async regmap writesRichard Fitzgerald1-18/+6
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 <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20250225131843.113752-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-02-23efi/cper: Fix cper_arm_ctx_info alignmentPatrick Rudolph1-1/+1
According to the UEFI Common Platform Error Record appendix, the processor context information structure is a variable length structure, but "is padded with zeros if the size is not a multiple of 16 bytes". Currently this isn't honoured, causing all but the first structure to be garbage when printed. Thus align the size to be a multiple of 16. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-02-23efi/cper: Fix cper_ia_proc_ctx alignmentPatrick Rudolph1-1/+1
According to the UEFI Common Platform Error Record appendix, the IA32/X64 Processor Context Information Structure is a variable length structure, but "is padded with zeros if the size is not a multiple of 16 bytes". Currently this isn't honoured, causing all but the first structure to be garbage when printed. Thus align the size to be a multiple of 16. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-02-22Merge tag 'soc-fixes-6.14' of ↵Linus Torvalds2-2/+3
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "Two people stepped up as platform co-maintainers: Andrew Jeffery for ASpeed and Janne Grunau for Apple. The rockchip platform gets 9 small fixes for devicetree files, addressing both compile-time warnings and board specific bugs. One bugfix for the optee firmware driver addresses a reboot-time hang. Two drivers need improved Kconfig dependencies to allow wider compile- testing while hiding the drivers on platforms that can't use them. ARM SCMI and loongson-guts drivers get minor bugfixes" * tag 'soc-fixes-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: soc: loongson: loongson2_guts: Add check for devm_kstrdup() tee: optee: Fix supplicant wait loop platform: cznic: CZNIC_PLATFORMS should depend on ARCH_MVEBU firmware: imx: IMX_SCMI_MISC_DRV should depend on ARCH_MXC MAINTAINERS: arm: apple: Add Janne as maintainer MAINTAINERS: Mark Andrew as M: for ASPEED MACHINE SUPPORT firmware: arm_scmi: imx: Correct tx size of scmi_imx_misc_ctrl_set arm64: dts: rockchip: adjust SMMU interrupt type on rk3588 arm64: dts: rockchip: disable IOMMU when running rk3588 in PCIe endpoint mode dt-bindings: rockchip: pmu: Ensure all properties are defined arm64: defconfig: Enable TISCI Interrupt Router and Aggregator arm64: dts: rockchip: Fix lcdpwr_en pin for Cool Pi GenBook arm64: dts: rockchip: fix fixed-regulator renames on rk3399-gru devices arm64: dts: rockchip: Disable DMA for uart5 on px30-ringneck arm64: dts: rockchip: Move uart5 pin configuration to px30 ringneck SoM arm64: dts: rockchip: change eth phy mode to rgmii-id for orangepi r1 plus lts arm64: dts: rockchip: Fix broken tsadc pinctrl names for rk3588
2025-02-21Merge tag 'scmi-fix-6.14' of ↵Arnd Bergmann1-2/+2
https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes Arm SCMI fix for v6.14 Just a single fix to address the incorrect size of the Tx buffer in the function scmi_imx_misc_ctrl_set() which is part of NXP/i.MX SCMI vendor extensions. * tag 'scmi-fix-6.14' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: imx: Correct tx size of scmi_imx_misc_ctrl_set Link: https://lore.kernel.org/r/20250217155246.1668182-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-02-18firmware: imx-scu: fix OF node leak in .probe()Joe Hattori1-0/+1
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 <joe@pf.is.s.u-tokyo.ac.jp> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-02-15Merge tag 'efi-fixes-for-v6.14-1' of ↵Linus Torvalds3-2/+10
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: "Take the newly introduced EFI_MEMORY_HOT_PLUGGABLE memory attribute into account when placing the kernel image in memory at boot. Otherwise, the presence of the kernel image could prevent such a memory region from being unplugged at runtime if it was 'cold plugged', i.e., already plugged in at boot time (and exposed via the EFI memory map). This should ensure that the new EFI_MEMORY_HOT_PLUGGABLE memory attribute is used consistently by Linux before it ever turns up in production, ensuring that we can make meaningful use of it without running the risk of regressing existing users" * tag 'efi-fixes-for-v6.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: Use BIT_ULL() constants for memory attributes efi: Avoid cold plugged memory for placing the kernel
2025-02-14firmware: imx: IMX_SCMI_MISC_DRV should depend on ARCH_MXCGeert Uytterhoeven1-0/+1
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 <geert+renesas@glider.be> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-02-13firmware: arm_scmi: imx: Correct tx size of scmi_imx_misc_ctrl_setPeng Fan1-2/+2
'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 <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>
2025-02-08firmware: qcom: uefisecapp: fix efivars registration raceJohan Hovold1-9/+9
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 <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>
2025-02-07Merge tag 'stable/for-linus-6.14-rc1-tag' of ↵Linus Torvalds2-2/+5
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/ibft Pull ibft fixes from Konrad Rzeszutek Wilk: "Two tiny fixes to IBFT code: one for Kconfig and another for IPv6" * tag 'stable/for-linus-6.14-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/ibft: iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic() firmware: iscsi_ibft: fix ISCSI_IBFT Kconfig entry
2025-02-05firmware: qcom: scm: Fix error code in probe()Dan Carpenter1-2/+2
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 <dan.carpenter@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/a0845467-4f83-4070-ab1e-ff7e6764609f@stanley.mountain Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-02-04efi: Avoid cold plugged memory for placing the kernelArd Biesheuvel3-2/+10
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>
2025-01-31Merge tag 'sound-fix-6.14-rc1' of ↵Linus Torvalds1-4/+2
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Here is a collection of fixes that have been gathered since the previous pull request. All about device-specific fixes and quirks, and most of them are pretty small and trivial" * tag 'sound-fix-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (25 commits) ALSA: hda/realtek: Workaround for resume on Dell Venue 11 Pro 7130 ALSA: hda: Fix headset detection failure due to unstable sort ALSA: pcm: use new array-copying-wrapper ASoC: codec: es8316: "DAC Soft Ramp Rate" is just a 2 bit control ASoC: amd: acp: Fix possible deadlock firmware: cs_dsp: FW_CS_DSP_KUNIT_TEST should not select REGMAP ALSA: usb-audio: Add delay quirk for iBasso DC07 Pro ALSA: hda/realtek: Fix quirk matching for Legion Pro 7 ASoC: renesas: SND_SIU_MIGOR should depend on DMADEVICES ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla 10 tablet 5V ASoC: da7213: Initialize the mutex ASoC: use to_platform_device() instead of container_of() ASoC: acp: Support microphone from Lenovo Go S ASoC: SOF: imx8m: Add entry for new 8M Plus revision ASoC: SOF: imx8: Add entries for new 8QM and 8QXP revisions ASoC: SOF: imx: Add mach entry to select cs42888 topology dt-bindings: arm: imx: Add board revisions for i.MX8MP, i.MX8QM and i.MX8QXP ASoC: fsl_asrc_m2m: select CONFIG_DMA_SHARED_BUFFER ASoC: audio-graph-card2: use correct endpoint when getting link parameters ASoC: SOF: imx8m: add SAI2,5,6,7 ...
2025-01-29iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()Chengen Du1-1/+4
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>
2025-01-29firmware: iscsi_ibft: fix ISCSI_IBFT Kconfig entryPrasad Pandit1-1/+1
Fix ISCSI_IBFT Kconfig entry, replace tab with a space character. Fixes: 138fe4e0697 ("Firmware: add iSCSI iBFT Support") Signed-off-by: Prasad Pandit <pjp@fedoraproject.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2025-01-28Merge tag 'driver-core-6.14-rc1' of ↵Linus Torvalds3-10/+10
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core and debugfs updates from Greg KH: "Here is the big set of driver core and debugfs updates for 6.14-rc1. Included in here is a bunch of driver core, PCI, OF, and platform rust bindings (all acked by the different subsystem maintainers), hence the merge conflict with the rust tree, and some driver core api updates to mark things as const, which will also require some fixups due to new stuff coming in through other trees in this merge window. There are also a bunch of debugfs updates from Al, and there is at least one user that does have a regression with these, but Al is working on tracking down the fix for it. In my use (and everyone else's linux-next use), it does not seem like a big issue at the moment. Here's a short list of the things in here: - driver core rust bindings for PCI, platform, OF, and some i/o functions. We are almost at the "write a real driver in rust" stage now, depending on what you want to do. - misc device rust bindings and a sample driver to show how to use them - debugfs cleanups in the fs as well as the users of the fs api for places where drivers got it wrong or were unnecessarily doing things in complex ways. - driver core const work, making more of the api take const * for different parameters to make the rust bindings easier overall. - other small fixes and updates All of these have been in linux-next with all of the aforementioned merge conflicts, and the one debugfs issue, which looks to be resolved "soon"" * tag 'driver-core-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (95 commits) rust: device: Use as_char_ptr() to avoid explicit cast rust: device: Replace CString with CStr in property_present() devcoredump: Constify 'struct bin_attribute' devcoredump: Define 'struct bin_attribute' through macro rust: device: Add property_present() saner replacement for debugfs_rename() orangefs-debugfs: don't mess with ->d_name octeontx2: don't mess with ->d_parent or ->d_parent->d_name arm_scmi: don't mess with ->d_parent->d_name slub: don't mess with ->d_name sof-client-ipc-flood-test: don't mess with ->d_name qat: don't mess with ->d_name xhci: don't mess with ->d_iname mtu3: don't mess wiht ->d_iname greybus/camera - stop messing with ->d_iname mediatek: stop messing with ->d_iname netdevsim: don't embed file_operations into your structs b43legacy: make use of debugfs_get_aux() b43: stop embedding struct file_operations into their objects carl9170: stop embedding file_operations into their objects ...
2025-01-28Merge tag 'char-misc-6.14-rc1' of ↵Linus Torvalds1-6/+3
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull Char/Misc/IIO driver updates from Greg KH: "Here is the "big" set of char/misc/iio and other smaller driver subsystem updates for 6.14-rc1. Loads of different things in here this development cycle, highlights are: - ntsync "driver" to handle Windows locking types enabling Wine to work much better on many workloads (i.e. games). The driver framework was in 6.13, but now it's enabled and fully working properly. Should make many SteamOS users happy. Even comes with tests! - Large IIO driver updates and bugfixes - FPGA driver updates - Coresight driver updates - MHI driver updates - PPS driver updatesa - const bin_attribute reworking for many drivers - binder driver updates - smaller driver updates and fixes All of these have been in linux-next for a while with no reported issues" * tag 'char-misc-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (311 commits) ntsync: Fix reference leaks in the remaining create ioctls. spmi: hisi-spmi-controller: Drop duplicated OF node assignment in spmi_controller_probe() spmi: Set fwnode for spmi devices ntsync: fix a file reference leak in drivers/misc/ntsync.c scripts/tags.sh: Don't tag usages of DECLARE_BITMAP dt-bindings: interconnect: qcom,msm8998-bwmon: Add SM8750 CPU BWMONs dt-bindings: interconnect: OSM L3: Document sm8650 OSM L3 compatible dt-bindings: interconnect: qcom-bwmon: Document QCS615 bwmon compatibles interconnect: sm8750: Add missing const to static qcom_icc_desc memstick: core: fix kernel-doc notation intel_th: core: fix kernel-doc warnings binder: log transaction code on failure iio: dac: ad3552r-hs: clear reset status flag iio: dac: ad3552r-common: fix ad3541/2r ranges iio: chemical: bme680: Fix uninitialized variable in __bme680_read_raw() misc: fastrpc: Fix copy buffer page size misc: fastrpc: Fix registered buffer page address misc: fastrpc: Deregister device nodes properly in error scenarios nvmem: core: improve range check for nvmem_cell_write() nvmem: qcom-spmi-sdam: Set size in struct nvmem_config ...
2025-01-27firmware: cs_dsp: FW_CS_DSP_KUNIT_TEST should not select REGMAPGeert Uytterhoeven1-4/+2
Enabling a (modular) test should not silently enable additional kernel functionality, as that may increase the attack vector of a product. Fix this by making FW_CS_DSP_KUNIT_TEST (and FW_CS_DSP_KUNIT_TEST_UTILS) depend on REGMAP instead of selecting it. After this, one can safely enable CONFIG_KUNIT_ALL_TESTS=m to build modules for all appropriate tests for ones system, without pulling in extra unwanted functionality, while still allowing a tester to manually enable REGMAP_BUILD and this test suite on a system where REGMAP is not enabled by default. Fixes: dd0b6b1f29b92202 ("firmware: cs_dsp: Add KUnit testing of bin file download") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://patch.msgid.link/73c81ac85e21f1c5a75b7628d90cbb0e1b4ed0fa.1737833376.git.geert@linux-m68k.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-25Merge tag 'efi-next-for-v6.14' of ↵Linus Torvalds13-444/+200
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI updates from Ard Biesheuvel: - Increase the headroom in the EFI memory map allocation created by the EFI stub. This is needed because event callbacks called during ExitBootServices() may cause fragmentation, and reallocation is not allowed after that. - Drop obsolete UGA graphics code and switch to a more ergonomic API to traverse handle buffers. Simplify some error paths using a __free() helper while at it. - Fix some W=1 warnings when CONFIG_EFI=n - Rely on the dentry cache to keep track of the contents of the efivarfs filesystem, rather than using a separate linked list. - Improve and extend efivarfs test cases. - Synchronize efivarfs with underlying variable store on resume from hibernation - this is needed because the firmware itself or another OS running on the same machine may have modified it. - Fix x86 EFI stub build with GCC 15. - Fix kexec/x86 false positive warning in EFI memory attributes table sanity check. * tag 'efi-next-for-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: (23 commits) x86/efi: skip memattr table on kexec boot efivarfs: add variable resync after hibernation efivarfs: abstract initial variable creation routine efi: libstub: Use '-std=gnu11' to fix build with GCC 15 selftests/efivarfs: add concurrent update tests selftests/efivarfs: fix tests for failed write removal efivarfs: fix error on write to new variable leaving remnants efivarfs: remove unused efivarfs_list efivarfs: move variable lifetime management into the inodes selftests/efivarfs: add check for disallowing file truncation efivarfs: prevent setting of zero size on the inodes in the cache efi: sysfb_efi: fix W=1 warnings when EFI is not set efi/libstub: Use __free() helper for pool deallocations efi/libstub: Use cleanup helpers for freeing copies of the memory map efi/libstub: Simplify PCI I/O handle buffer traversal efi/libstub: Refactor and clean up GOP resolution picker code efi/libstub: Simplify GOP handling code efi/libstub: Use C99-style for loop to traverse handle buffer x86/efistub: Drop long obsolete UGA support efivarfs: make variable_is_present use dcache lookup ...
2025-01-25Merge tag 'soc-drivers-6.14' of ↵Linus Torvalds10-42/+330
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC driver updates from Arnd Bergmann: "These are changes to SoC specific drivers and DT bindings that don't have a separate subsystem tree, or that get grouped here for simplicity. Nothing out of the ordinary for the 6.14 release here: - Most of the updates are for Qualcomm specific drivers, adding support for additional SoCs in the exssting drivers, and support for wrapped encryption key access in the SCM firmware. - The Arm SCMI firmware code gains support for having multiple instances of firmware running, and better module auto loading. - A few minor updates for litex, samsung, ti, tegra, mediatek, imx and renesas platforms. - Reset controller updates for amlogic, to add support for the A1 soc and clean up the existing code. - Memory controller updates for ti davinci aemif, refactoring the code and adding a few interfaces to other drivers" * tag 'soc-drivers-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (58 commits) drivers/soc/litex: Use devm_register_restart_handler() reset: amlogic: aux: drop aux registration helper reset: amlogic: aux: get regmap through parent device reset: amlogic: add support for A1 SoC in auxiliary reset driver dt-bindings: reset: add bindings for A1 SoC audio reset controller soc/tegra: fuse: Update Tegra234 nvmem keepout list soc/tegra: Fix spelling error in tegra234_lookup_slave_timeout() soc/tegra: cbb: Drop unnecessary debugfs error handling firmware: qcom: scm: add calls for wrapped key support soc: qcom: pd_mapper: Add SM7225 compatible dt-bindings: firmware: qcom,scm: Document ipq5424 SCM soc: qcom: llcc: Update configuration data for IPQ5424 dt-bindings: cache: qcom,llcc: Add IPQ5424 compatible soc: mediatek: mtk-devapc: Fix leaking IO map on driver remove soc: mediatek: mtk-devapc: Fix leaking IO map on error paths firmware: qcom: scm: smc: Narrow 'mempool' variable scope firmware: qcom: scm: smc: Handle missing SCM device firmware: qcom: scm: Cleanup global '__scm' on probe failures firmware: qcom: scm: Fix missing read barrier in qcom_scm_get_tzmem_pool() firmware: qcom: scm: Fix missing read barrier in qcom_scm_is_available() ...
2025-01-24Merge tag 'sound-6.14-rc1' of ↵Linus Torvalds17-0/+17067
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound updates from Takashi Iwai: "This was a relatively calm cycle, and most of changes are rather small device-specific fixes. Here are highlights: Core: - Further enhancements of ALSA rawmidi and sequencer APIs for MIDI 2.0 - compress-offload API extensions for ASRC support ASoC: - Allow clocking on each DAI in an audio graph card to be configured separately - Improved power management for Renesas RZ-SSI - KUnit testing for the Cirrus DSP framework - Memory to meory operation support for Freescale/NXP platforms - Support for pause operations in SOF - Support for Allwinner suinv F1C100s, Awinc AW88083, Realtek ALC5682I-VE HD- and USB-audio: - Add support for Focusrite Scarlett 4th Gen 16i16, 18i16, and 18i20 interfaces via new FCP driver - TAS2781 SPI HD-audio sub-codec support - Various device-specific quirks as usual" * tag 'sound-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (235 commits) ALSA: hda: tas2781-spi: Fix bogus error handling in tas2781_hda_spi_probe() ALSA: hda: tas2781-spi: Fix error code in tas2781_read_acpi() ALSA: hda: tas2781-spi: Delete some dead code ALSA: usb: fcp: Fix return code from poll ops ALSA: usb: fcp: Fix incorrect resp->opcode retrieval ALSA: usb: fcp: Fix meter_levels type to __le32 ALSA: hda/realtek: Enable Mute LED on HP Laptop 14s-fq1xxx ALSA: hda: tas2781-spi: Fix -Wsometimes-uninitialized in tasdevice_spi_switch_book() ALSA: ctxfi: Simplify dao_clear_{left,right}_input() functions ALSA: hda: tas2781-spi: select CRC32 instead of CRC32_SARWATE ALSA: usb: fcp: Fix hwdep read ops types ALSA: scarlett2: Add device_setup option to use FCP driver ALSA: FCP: Add Focusrite Control Protocol driver ALSA: hda/tas2781: Add tas2781 hda SPI driver ALSA: hda/realtek - Fixed headphone distorted sound on Acer Aspire A115-31 laptop ASoC: xilinx: xlnx_spdif: Simpify using devm_clk_get_enabled() ALSA: hda: Support for Ideapad hotkey mute LEDs ASoC: Intel: sof_sdw: Fix DMI match for Lenovo 83JX, 83MC and 83NM ASoC: Intel: sof_sdw: Fix DMI match for Lenovo 83LC ASoC: dapm: add support for preparing streams ...
2025-01-22efi: libstub: Use '-std=gnu11' to fix build with GCC 15Nathan Chancellor1-1/+1
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>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-20 22:55:22 +0300