summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-06-11Merge branches 'pm-sleep', 'pm-powercap' and 'pm-tools'refs/merge-window/b7b9fef85ccd38cebf187688b321fb1bd2429d63Rafael J. Wysocki
Merge updates related to system sleep support, two updates of the intel_rapl power capping driver, and a pm-graph utility fix for 7.2-rc1: - Add sysctl interface for DPM watchdog timeouts (Tzung-Bi Shih) - Use complete() instead of complete_all() in device_pm_sleep_init() to avoid a false-positive warning from lockdep_assert_RT_in_threaded_ctx() when CONFIG_PROVE_RAW_LOCK_NESTING is enabled (Jiakai Xu) - Use a flexible array for CRC uncompressed buffers during hibernation image saving (Rosen Penev) - Make the LZ4 algorithm available for hibernation compression (l1rox3) - Move the preallocate_image() call during hibernation after the "prepare" phase of the "freeze" transition (Matthew Leach) - Fix a memory leak in rapl_add_package_cpuslocked() in the intel_rapl power capping driver and use sysfs_emit() in cpumask_show() in that driver (Sumeet Pawnikar, Yury Norov) - Fix ValueError when parsing incomplete device properties in the pm-graph utility (Gongwei Li) * pm-sleep: PM: dpm_watchdog: Add sysctl interface for DPM watchdog timeouts PM: hibernate: Use flexible array for CRC uncompressed buffers PM: hibernate: make LZ4 available for hibernation compression PM: sleep: Use complete() in device_pm_sleep_init() PM: hibernate: call preallocate_image() after freeze prepare * pm-powercap: powercap: intel_rapl: Use sysfs_emit() in cpumask_show() powercap: intel_rapl: Fix memory leak in rapl_add_package_cpuslocked() * pm-tools: PM: tools: pm-graph: fix ValueError when parsing incomplete device properties
2026-06-11ASoC: SOF: Intel: hda-sdw-bpt: select SND_SOF_SOF_HDA_SDW_BPT properlyArnd Bergmann
When SND_SOC_SOF_INTEL_LNL is set, SND_SOF_SOF_HDA_SDW_BPT must also be enabled, in order to let the soundwire support call into it. However, there are configurations with SND_SOF_SOF_HDA_SDW_BPT=m and SND_SOF_SOF_HDA_SDW_BPT=m but SOUNDWIRE_INTEL=y, which still lead to a link failure: aarch64-linux-ld: drivers/soundwire/intel_ace2x.o: in function `intel_ace2x_bpt_wait': intel_ace2x.c:(.text+0xfc8): undefined reference to `hda_sdw_bpt_wait' aarch64-linux-ld: drivers/soundwire/intel_ace2x.o: in function `intel_ace2x_bpt_send_async': intel_ace2x.c:(.text+0x1ff8): undefined reference to `hda_sdw_bpt_get_buf_size_alignment' Address this by moving the 'select SND_SOF_SOF_HDA_SDW_BPT' into SND_SOC_SOF_HDA_GENERIC. Fixes: 614d416dd8ae ("ASoC: SOF: Intel: hda-sdw-bpt: fix SND_SOF_SOF_HDA_SDW_BPT dependencies") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260611132310.137688-2-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-11ASoC: SOF: Intel: select SND_SOC_SDW_UTILS=y from SND_SOC_SOF_HDA_GENERIC=yArnd Bergmann
When SND_SOC_SOF_HDA_GENERIC=y but SND_SOC_SOF_INTEL_SOUNDWIRE=m, the SND_SOC_SDW_UTILS is also set to =m even though there is a direct link dependency from the hda.c: aarch64-linux-ld: sound/soc/sof/intel/hda.o: in function `hda_machine_select': hda.c:(.text+0x21ac): undefined reference to `codec_info_list' hda.c:(.text+0x241c): undefined reference to `asoc_sdw_get_dai_type' hda.c:(.text+0x25b4): undefined reference to `asoc_sdw_get_codec_info_list_count' hda.c:(.text+0x25d8): undefined reference to `asoc_sdw_get_codec_info_list_count' Change this the same way as the other related 'select' statements to allow linking against it. Fixes: 2b4d53eb5cf3 ("ASoC: SOF: Intel: select SND_SOC_SDW_UTILS in SND_SOC_SOF_HDA_GENERIC") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Julian Braha <julianbraha@gmail.com> Link: https://patch.msgid.link/20260611132310.137688-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-11ASoC: cs35l56: Fix wrong error test on simple_write_to_buffer()Richard Fitzgerald
In cs35l56_cal_data_debugfs_write() fix the if statement that checks for error return to only check for negative values. Reported by Sashiko: simple_write_to_buffer() returns the positive number of bytes copied on success. Since the condition returns immediately on any non-zero value, is it possible that the written calibration data is discarded and cs35l56_stash_calibration() is never called? Fixes: f7097161e94c ("ASoC: cs35l56: Add common code for factory calibration") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://sashiko.dev/#/patchset/20260610093432.557375-1-rf%40opensource.cirrus.com Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260611151234.1111153-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-11ASoC: soc-core: Create device_link to ensure correct suspend orderRichard Fitzgerald
In snd_soc_bind_card() create a device_link from card to all components to ensure correct order of system_suspend. The card is the consumer and the components are the supplier, so that the card will system_suspend before any of the components. The PM core will normally system_suspend drivers in the opposite order that they registered. This ensures children are suspended before their parents, for example users of a bus driver should suspend before the bus driver suspends. For ASoC, snd_soc_suspend() shuts down any active audio, which requires that the components are still able to communicate with their hardware. Previously there was nothing to ensure this ordering, because there is (usually) no relationship between a machine driver and component drivers. If the machine driver registered before the codec drivers, the codec drivers would be suspended before the machine driver snd_soc_suspend() runs, so that ASoC is attempting to stop audio on a driver that has already suspended. Creating a device_link is safe if there is already a device_link between those devices because of multiple components sharing the same dev. device_link_add() kernel doc says: "if a device link between the given @consumer and @supplier pair exists already when this function is called for them, the existing link will be returned regardless of its current type and status ... The caller of this function is then expected to treat the link as though it has just been created, so (in particular) if DL_FLAG_STATELESS was passed in @flags, the link needs to be released explicitly when not needed any more" For the same reason it is safe if the codec driver or machine driver later call device_link_add() to create a link between the same two devices. (I have tested creating multiple links between the card->dev and a component->dev and did not encounter any problems with suspend/resume or module unloading.) The DL_FLAG_AUTOREMOVE_* flags assume that they are being called from the probe() function of that device. This isn't guaranteed in ASoC card binding because of deferred binding. The exact behavior and consequences of the DL_FLAG_AUTOREMOVE_* are also unclear from the documentation. So DL_FLAG_STATELESS is used for safety, and the links are removed explicitly when the card unbinds or if the bind fails. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260611110856.1088110-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-11PM: dpm_watchdog: Add sysctl interface for DPM watchdog timeoutsTzung-Bi Shih
Introduce sysctl knobs to allow configuring DPM watchdog timeouts at runtime. Currently, these timeouts are fixed at compile time via CONFIG_DPM_WATCHDOG_TIMEOUT and CONFIG_DPM_WATCHDOG_WARNING_TIMEOUT. This limits flexibility if the timeouts need to be adjusted for different testing scenarios or hardware behaviors without rebuilding the kernel. Add the following sysctl files under /proc/sys/kernel/: - dpm_watchdog_timeout_secs: The total timeout before panic. The maximum value is capped at CONFIG_DPM_WATCHDOG_TIMEOUT to prevent unreasonably large timeouts. - dpm_watchdog_warning_timeout_secs: The warning timeout. The maximum value is capped at the current dpm_watchdog_timeout_secs. Both sysctls have a minimum value of 1. Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://patch.msgid.link/20260608021526.1023248-4-tzungbi@kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-06-11Merge tag 'asoc-fix-v7.1-rc7' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v7.1 A few more fixes for this release, some smaller driver specific ones plus a final quirk.
2026-06-11Merge branches 'pm-cpuidle', 'pm-opp' and 'pm-qos'Rafael J. Wysocki
Merge cpuidle updates, OPP (operating performance points) updates and a PM QoS update for 7.2-rc1: - Allow the intel_idle driver to avoid exposing C-states that are redundant when PC6 is disabled (Artem Bityutskiy) - Fix memory leak and a potential race in the OPP core (Abdun Nihaal, Di Shen) - Mark Rust OPP methods as inline (Nicolás Antinori) - Fix misc device registration failure path in the PM QoS core (Yuho Choi) * pm-cpuidle: intel_idle: Drop C-states redundant when PC6 is disabled intel_idle: Introduce a helper for checking PC6 intel_idle: Add constants for MSR_PKG_CST_CONFIG_CONTROL * pm-opp: opp: rust: mark OPP methods as inline OPP: of: Fix potential memory leak in opp_parse_supplies() OPP: Fix race between OPP addition and lookup * pm-qos: PM: QoS: Fix misc device registration unwind
2026-06-11Merge branch 'pm-cpufreq'Rafael J. Wysocki
Merge cpufreq updates for 7.2: - Fix a race between cpufreq suspend and CPU hotplug during system shutdown (Tianxiang Chen) - Avoid redundant target() calls for unchanged limits and fix a typo in a comment in the cpufreq core (Viresh Kumar) - Fix concurrency issues related to sysfs attributes access that affect cpufreq governors using the common governor code (Zhongqiu Han) - Simplify frequency limit handling in the conservative cpufreq governor (Lifeng Zheng) - Fix descriptions of the conservative governor freq_step tunable and the ondemand governor sampling_down_factor tunable in the cpufreq documentation (Pengjie Zhang) - Fix use-after-free and double free during _OSC evaluation in the PCC cpufreq driver (Yuho Choi) - Rework the handling of policy min and max frequency values in the cpufreq core to allow drivers to specify special initial values for the scaling_min_freq and scaling_max_freq sysfs attributes (Pierre Gondois) - Add cpufreq scaling support for Qualcomm Shikra SoC (Taniya Das, Imran Shaik). - Improve the warning message on HWP-disabled hybrid processors printed by the intel_pstate driver and sync policy->cur during CPU offline in it (Yohei Kojima, Fushuai Wang) - Drop cpufreq support for AMD Elan SC4* (Sean Young) - Minor fixes for cpufreq drivers (Krzysztof Kozlowski, Akashdeep Kaur, Hans Zhang, Guangshuo Li, Xueqin Luo) - Clean up dead dependencies on X86 in the cpufreq Kconfig (Julian Braha) * pm-cpufreq: (25 commits) cpufreq: Use policy->min/max init as QoS request cpufreq: Remove driver default policy->min/max init cpufreq: Set default policy->min/max values for all drivers cpufreq: Extract cpufreq_policy_init_qos() function cpufreq: Documentation: fix conservative governor freq_step description cpufreq: ti: Add EPROBE_DEFER for K3 SoCs cpufreq: qcom: Add cpufreq scaling support for Qualcomm Shikra SoC dt-bindings: cpufreq: Document Qualcomm Shikra SoC EPSS cpufreq: governor: Fix stale prev_cpu_nice spike when enabling ignore_nice_load cpufreq: governor: Fix data races on per-CPU idle/nice baselines cpufreq: intel_pstate: Improve warning message on HWP-disabled hybrid CPUs cpufreq: elanfreq: Drop support for AMD Elan SC4* cpufreq: clean up dead dependencies on X86 in Kconfig cpufreq: conservative: Simplify frequency limit handling cpufreq: Avoid redundant target() calls for unchanged limits cpufreq: Fix typo in comment cpufreq: intel_pstate: Sync policy->cur during CPU offline cpufreq: Documentation: fix sampling_down_factor range cpufreq: Fix hotplug-suspend race during reboot cpufreq: pcc: fix use-after-free and double free in _OSC evaluation ...
2026-06-11RDMA/mlx5: Release the HW‑provided UAR index rather than the SW oneLeon Romanovsky
Free the UAR index returned by the hardware. Fixes: 4ed131d0bb15 ("IB/mlx5: Expose dynamic mmap allocation") Link: https://patch.msgid.link/r/20260611-fix-uar-release-v1-1-f5464d845dbf@nvidia.com Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-11RDMA/mlx5: Fix undefined shift of user RQ WQE sizeMaher Sanalla
set_rq_size() computes the RQ WQE size as "1 << rq_wqe_shift" based on the user-provided rq_wqe_shift, which is only checked to be greater than 32, so shifts of 32 are still accepted. A shift of 31 also overflows a signed integer, leading to undefined behavior. Use check_shl_overflow() to compute the RQ WQE size and reject any invalid values. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Link: https://patch.msgid.link/r/20260611-maher-sec-fixes-v1-1-cd8eb2542869@nvidia.com Signed-off-by: Maher Sanalla <msanalla@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-11RDMA/mlx5: Remove raw RSS QP restrack trackingPatrisious Haddad
Raw RSS QP restrack tracking wasn't working to begin with as it was only tracking the first raw RSS QP which was added, since at creation the raw RSS QP number is reserved so the QP number for this qp type was always zero. The following raw RSS QP additions were always failing silently. Since the fix isn't trivial and there were no users that required or complained about this issue we are dropping this for now instead of fixing. Fixes: 968f0b6f9c01 ("RDMA/mlx5: Consolidate into special function all create QP calls") Link: https://patch.msgid.link/r/20260607-restrack-uaf-fix-v1-2-d72e45eb76c2@nvidia.com Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Reviewed-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-11RDMA/mlx5: Remove DCT restrack trackingPatrisious Haddad
DCT restrack tracking wasn't working to begin with as it was only tracking the first DCT which was added, since at creation the DCT number isn't yet initialized because the DCT FW object is only created during modify. The following DCT additions were failing silently. Since the fix isn't trivial and there were no users that required or complained about this issue we are dropping this for now instead of fixing. Fixes: fd3af5e21866 ("RDMA/mlx5: Track DCT, DCI and REG_UMR QPs as diver_detail resources.") Link: https://patch.msgid.link/r/20260607-restrack-uaf-fix-v1-1-d72e45eb76c2@nvidia.com Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Reviewed-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-11lib/test_firmware: allocate the configured into_buf sizeSamuel Moelius
The batched into_buf test path allocates TEST_FIRMWARE_BUF_SIZE bytes unconditionally, but then passes test_fw_config->buf_size to request_firmware_into_buf() or request_partial_firmware_into_buf(). Userspace can set config_buf_size above TEST_FIRMWARE_BUF_SIZE before triggering a batched request. If the firmware file is large enough, the firmware loader writes past the end of the 1 KiB test buffer. Allocate the buffer with the same size that the test passes to the firmware API so config_buf_size remains the actual buffer size under test. Assisted-by: Codex:gpt-5.5-cyber-preview Link: https://lore.kernel.org/20260605003038.2005840-1-sam.moelius@trailofbits.com Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: Kees Cook <kees@kernel.org> Cc: Luis R. Rodriguez <mcgrof@kernel.org> Cc: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-06-11fs: efs: remove unneeded debug printsMaxwell Doose
The current code uses debug prints conditionally compiled with #ifdef DEBUG. However, that code, when compiled, causes compiler errors due to incompatible formatters and undefined variables, notably: fs/efs/file.c: In function `efs_get_block': fs/efs/file.c:26:35: error: `block' undeclared (first use in this function); did you mean `iblock'? 26 | __func__, block, inode->i_blocks, inode->i_size); | ^~~~~ and: fs/efs/file.c: In function `efs_bmap': ./include/linux/kern_levels.h:5:25: error: format `%ld' expects argument of type `long int', but argument 4 has type `blkcnt_t' {aka `long long unsigned int'} [-Werror=format=] 5 | #define KERN_SOH "\001" /* ASCII Start Of Header */ | ^~~~~~ which also extends to the other formatters. As this part of the code has been dead for just about 14 years now, it has not been modernized to stay compatible with the most recent gcc compilers. Fix these issues by removing the debug prints. Link: https://lore.kernel.org/20260605035251.89305-2-m32285159@gmail.com Fixes: f403d1dbac6d ("fs/efs: add pr_fmt / use __func__") Signed-off-by: Maxwell Doose <m32285159@gmail.com> Suggested-by: Andrew Morton <akpm@linux-foundation.org> Cc: Fabian Frederick <fabf@skynet.be> Cc: Christian Brauner <brauner@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-06-11checkpatch: cuppress warnings when Reported-by: is followed by Link:Cryolitia PukNgae
> The tag should be followed by a Closes: tag pointing to the report, > unless the report is not available on the web. The Link: tag can be > used instead of Closes: if the patch fixes a part of the issue(s) > being reported. According to Documentation/process/submitting-patches.rst, Link: is also acceptable to follow a Reported-by:, if the patch fixes a part of the issue(s) being reported. Link: https://lore.kernel.org/20260605-checkpatch-v1-1-8c68ae618513@linux.dev Signed-off-by: Cryolitia PukNgae <cryolitia@uniontech.com> Reviewed-by: Petr Vorel <pvorel@suse.cz> Cc: Andy Whitcroft <apw@canonical.com> Cc: Cheng Nie <niecheng1@uniontech.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-06-11MAINTAINERS: add Alexander as a kcov reviewerAlexander Potapenko
Also move Dmitry Vyukov to the bottom of the list. Link: https://lore.kernel.org/20260605085423.1962700-1-glider@google.com Signed-off-by: Alexander Potapenko <glider@google.com> Reviewed-by: Dmitry Vyukov <dvyukov@google.com> Cc: Alexander Potapenko <glider@google.com> Cc: Marco Elver <elver@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-06-11mailmap: update Alexander Sverdlin's Email addressesAlexander Sverdlin
- add kernel.org address - add sverdlin.org address (as primary address) - drop siemens.com address (for accounting purposes only) Link: https://lore.kernel.org/20260603225847.1849399-1-asv@kernel.org Signed-off-by: Alexander Sverdlin <asv@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-06-11fs: fat: inode: replace sprintf() with scnprintf()Maxwell Doose
The kernel documentation notes that sprintf() is deprecated and unsafe. Replace it with the more preferred scnprintf() to help with hardening. Link: https://lore.kernel.org/20260603145222.59012-1-m32285159@gmail.com Signed-off-by: Maxwell Doose <m32285159@gmail.com> Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-06-11RDMA/mlx5: Drop FRMR pool handle on UMR revoke failureMichael Guralnik
When UMR revoke fails during MR cleanup, the handle is left in an unknown state and cannot be returned to the pool. The driver already destroys the mkey via the fallback path, but the pool's in_use counter is never decremented, drifting upward over time. Call ib_frmr_pool_drop on the revoke-failure path so the pool's accounting stays consistent with the handles it has handed out. Fixes: 36680ef7bceb ("RDMA/mlx5: Switch from MR cache to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-10-michaelgur@nvidia.com Signed-off-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-11RDMA/core: Add ib_frmr_pool_drop for unrecoverable handlesMichael Guralnik
A driver that has popped a handle from an FRMR pool can hit failures that leave the handle in a state where it can't safely be returned for reuse. The driver destroys the handle itself, but the pool has no way to learn about it, so the in_use counter drifts upward. Add ib_frmr_pool_drop to balance the pool's accounting in this case. Every pop is now balanced by exactly one push or drop. Fixes: 36680ef7bceb ("RDMA/mlx5: Switch from MR cache to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-9-michaelgur@nvidia.com Signed-off-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-11RDMA/core: Fix FRMR handle leak on push failureMichael Guralnik
Failure to push a handle to the pool, caused by ENOMEM on queue page allocation, will trigger missing in_use counter update, skewing pool state indefinitely. Fix that by moving the handling of handle destruction in such case into the FRMR code, ensuring the handle is either pushed to the pool or destroyed inside the same function. Adjust mlx5_ib call site accordingly. Fixes: ce5df0b891ed ("IB/core: Introduce FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-8-michaelgur@nvidia.com Signed-off-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-11RDMA/core: Avoid NULL dereference on FRMR bad usageMichael Guralnik
In case a driver calls FRMR pop operation without a successful init, return after triggering a warning to avoid the NULL dereference. Fixes: ce5df0b891ed ("IB/core: Introduce FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-7-michaelgur@nvidia.com Signed-off-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-11RDMA/core: Fix FRMR set pinned push error pathMichael Guralnik
Add destruction of FRMR handles in case the push to the pool fails. This prevents resources leak in case pool page allocation fails. Fixes: 020d189d16a6 ("RDMA/core: Add pinned handles to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-6-michaelgur@nvidia.com Signed-off-by: Michael Guralnik <michaelgur@nvidia.com> Reviewed-by: Tao Cui <cuitao@kylinos.cn> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-11RDMA/core: Fix FRMR aging push to queue error flowMichael Guralnik
Aging pools with pinned handles requires moving handles from the active queue to a non-empty inactive queue that might fail on new page allocation, we are currently not handling the fault and leaking any mkey that fails the push. Fix by Introducing push_queue_to_queue_locked() that fills the destination's partial tail page from the source and then splices the remaining source pages onto the destination, performing no allocation. Replace the per-handle move loop in age_pinned_pool() and the open-coded splice in pool_aging_work() with calls to the helper. As the helper cannot fail under memory pressure, removing a class of GFP_ATOMIC allocations under the pool lock and simplifying the error flow. Fixes: 020d189d16a6 ("RDMA/core: Add pinned handles to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-5-michaelgur@nvidia.com Signed-off-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-11RDMA/core: Fix skipped usage for driver built FRMR keyMichael Guralnik
When creating FRMR handles following a netlink command to pin handles, use the key after driver callback instead of using the key passed directly from user. Fixes: 020d189d16a6 ("RDMA/core: Add pinned handles to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-4-michaelgur@nvidia.com Signed-off-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-11RDMA/mlx5: Fix TPH extraction in FRMR pool keyMichael Guralnik
Fix reading the PH value from the FRMR pool key by shifting the pool key to the relevant bits. Fixes: 36680ef7bceb ("RDMA/mlx5: Switch from MR cache to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-3-michaelgur@nvidia.com Signed-off-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-11RDMA/mlx5: Fix mkey creation error flow rollbackMichael Guralnik
Fix the indices of mkeys destroyed in case of an error in batch mkey creation. Fixes: 36680ef7bceb ("RDMA/mlx5: Switch from MR cache to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-2-michaelgur@nvidia.com Signed-off-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-11MAINTAINERS: Update address for David HeidelbergDavid Heidelberg
The +nfc postfix is not useful as I thought. Use the default email. Signed-off-by: David Heidelberg <david@ixit.cz>
2026-06-11nfc: Use named initializers for struct i2c_device_idUwe Kleine-König (The Capable Hub)
While being less compact, using named initializers allows to more easily see which members of the structs are assigned which value without having to lookup the declaration of the struct. And it's also more robust against changes to the struct definition. While touching all these arrays, unify usage of whitespace in the list terminator. This patch doesn't modify the compiled arrays, only their representation in source form benefits. The former was confirmed with x86 and arm64 builds. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260518133311.644160-2-u.kleine-koenig@baylibre.com Signed-off-by: David Heidelberg <david@ixit.cz>
2026-06-11nfc: nxp-nci: treat -ENXIO in IRQ thread as no data availableCarl Lee
The I2C read operation in the IRQ thread may return -ENXIO when the controller has not yet provided data after asserting IRQ. IRQ assertion does not guarantee that data is immediately available on the I2C bus. In such cases, the read request may be NACKed, resulting in -ENXIO. Treat this condition as "no data available yet" and log it at debug level instead of reporting it as a read failure. This avoids misleading error messages during normal operation. Signed-off-by: Carl Lee <carl.lee@amd.com> Link: https://patch.msgid.link/20260526-nfc-nxp-nci-treat-enxio-as-no-data-available-yet-v1-1-305bb11b9147@amd.com Signed-off-by: David Heidelberg <david@ixit.cz>
2026-06-11Bluetooth: btintel_pcie: Separate coredump work from RX workRavindra
Sharing a single workqueue between coredump processing and RX delays evacuation of RX events while a coredump is in progress. The firmware's RX buffers can overflow during that window, leading to dropped events. The issue was observed in HID use cases where HID reports arrive in bursts and quickly fill the RX path while a coredump is being collected. Move coredump processing to a dedicated ordered coredump_workqueue with its own coredump_work, so coredumps run independently of RX. All four coredump trigger sources (FW assert, HW exception, user sysfs trigger, and resume-error detection) are switched to this new workqueue. Ordering serialises concurrent triggers without blocking RX. Signed-off-by: Ravindra <ravindra@intel.com> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()Sergey Senozhatsky
Every once in a while we see a hung btmtksdio_flush() task: INFO: task kworker/u17:0:189 blocked for more than 122 seconds. __cancel_work_timer+0x3f4/0x460 cancel_work_sync+0x1c/0x2c btmtksdio_flush+0x2c/0x40 hci_dev_open_sync+0x10c4/0x2190 [..] It all boils down to incorrect time_is_before_jiffies() usage in btmtksdio_txrx_work(). The btmtksdio_txrx_work() loop is expected to be terminated if running for longer than 5*HZ. However the timeout check is twisted: time_is_before_jiffies(old_jiffies + 5*HZ) evaluates to true when old_jiffies + 5*HZ is in the past i.e. when a timeout has occurred. Using OR with time_is_before_jiffies(txrx_timeout) means that: - before the 5-second timeout: the condition is `int_status || false`, so it loops as long as there are pending interrupts. - after the 5-second timeout: the condition becomes `int_status || true`, which is always true. When the loop becomes infinite btmtksdio_txrx_work() loop never terminates and never releases the SDIO host. Fix loop termination condition to actually enforce a 5*HZ timeout. Fixes: 26270bc189ea4 ("Bluetooth: btmtksdio: move interrupt service to work") Cc: stable@vger.kernel.org Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: qca: Add BT FW build version to kernel logXiuzhuo Shang
Firmware version is critical for bug triage. Users reporting issues typically share dmesg output rather than debugfs contents, requiring extra communication rounds to collect this information. Log the FW build version directly to the kernel log so it is immediately available in bug reports. Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Xiuzhuo Shang <xiuzhuo.shang@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: vhci: validate devcoredump state before side effectsSamuel Moelius
The VHCI force_devcoredump debugfs hook accepts a small test record from userspace. It validates the requested terminal state only after registering, initializing and appending a Bluetooth devcoredump. As a result, an invalid state returns -EINVAL but still leaves queued devcoredump work behind. With a non-zero timeout field, the rejected write can still emit a devcoredump after the timeout expires. Reject unsupported states before allocating the skb or changing the HCI devcoredump state machine. Fixes: ab4e4380d4e1 ("Bluetooth: Add vhci devcoredump support") Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: L2CAP: validate connectionless PSM lengthSamuel Moelius
Connectionless L2CAP frames carry a two-byte PSM at the start of the payload. l2cap_recv_frame() currently reads that PSM unconditionally after validating only the outer L2CAP length. A malformed connectionless frame with a zero- or one-byte payload can therefore make the parser read beyond the advertised skb payload and use tailroom bytes as part of the PSM. A VHCI-backed QEMU reproducer injected a one-byte connectionless payload and reached the unchecked read. Reject connectionless frames that cannot contain the PSM before reading or pulling it. This preserves all valid connectionless frames while dropping only structurally incomplete packets. Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: hci: validate codec capability element lengthSamuel Moelius
Read Local Codec Capabilities returns a sequence of capability elements. Each element starts with a one-byte length followed by that many payload bytes. hci_read_codec_capabilities() checks that the skb contains the length byte, but then validates only caps->len against the remaining skb length. A malformed controller response with one remaining byte and caps->len set to one passes that check even though the element needs two bytes. The parser then records a two-byte capability and copies one byte beyond the advertised response payload into the codec list. Validate the full element size, including the length byte, before adding it to the accumulated capability length. This preserves all well-formed capability elements and drops only truncated controller responses. Fixes: 8961987f3f5f ("Bluetooth: Enumerate local supported codec and cache details") Assisted-by: Codex:gpt-5.5-cyber-preview Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn refMarco Elver
l2cap_chan_timeout() runs asynchronously and accesses chan->conn. If the connection is torn down while the timer is running or pending, chan->conn can be freed, leading to a use-after-free when the timer worker attempts to lock conn->lock: | BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 [inline] | BUG: KASAN: slab-use-after-free in atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline] | BUG: KASAN: slab-use-after-free in __mutex_trylock_fast kernel/locking/mutex.c:161 [inline] | BUG: KASAN: slab-use-after-free in mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318 | Write of size 8 at addr ffff8881298d9550 by task kworker/2:1/83 | | CPU: 2 UID: 0 PID: 83 Comm: kworker/2:1 Not tainted 7.1.0-rc6-next-20260601-dirty #6 PREEMPT(full) | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 | Workqueue: events l2cap_chan_timeout | Call Trace: | <TASK> | instrument_atomic_read_write include/linux/instrumented.h:112 [inline] | atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline] | __mutex_trylock_fast kernel/locking/mutex.c:161 [inline] | mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318 | l2cap_chan_timeout+0x5d/0x1b0 net/bluetooth/l2cap_core.c:422 | process_one_work kernel/workqueue.c:3326 [inline] | process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409 | worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490 | kthread+0x346/0x430 kernel/kthread.c:436 | ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158 | ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 | </TASK> | | Allocated by task 320: | l2cap_conn_add+0xa7/0x820 net/bluetooth/l2cap_core.c:7075 | l2cap_connect_cfm+0xdb/0xd70 net/bluetooth/l2cap_core.c:7452 | hci_connect_cfm include/net/bluetooth/hci_core.h:2139 [inline] | hci_remote_features_evt+0x52f/0x9f0 net/bluetooth/hci_event.c:3760 | hci_event_func net/bluetooth/hci_event.c:7796 [inline] | hci_event_packet+0x561/0xa70 net/bluetooth/hci_event.c:7847 | hci_rx_work+0x370/0x890 net/bluetooth/hci_core.c:4040 | process_one_work kernel/workqueue.c:3326 [inline] | process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409 | worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490 | kthread+0x346/0x430 kernel/kthread.c:436 | ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158 | ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 | | Freed by task 322: | hci_disconn_cfm include/net/bluetooth/hci_core.h:2154 [inline] | hci_conn_hash_flush+0x101/0x1f0 net/bluetooth/hci_conn.c:2736 | hci_dev_close_sync+0x889/0xde0 net/bluetooth/hci_sync.c:5405 | hci_dev_do_close net/bluetooth/hci_core.c:502 [inline] | hci_unregister_dev+0x1f7/0x370 net/bluetooth/hci_core.c:2679 | vhci_release+0x12a/0x180 drivers/bluetooth/hci_vhci.c:690 | __fput+0x369/0x890 fs/file_table.c:510 | task_work_run+0x160/0x1d0 kernel/task_work.c:233 | get_signal+0xf5b/0x1120 kernel/signal.c:2810 | arch_do_signal_or_restart+0x4d/0x600 arch/x86/kernel/signal.c:337 | __exit_to_user_mode_loop kernel/entry/common.c:64 [inline] | exit_to_user_mode_loop+0x85/0x510 kernel/entry/common.c:98 | do_syscall_64+0x263/0x3d0 arch/x86/entry/syscall_64.c:100 | entry_SYSCALL_64_after_hwframe+0x77/0x7f | | The buggy address belongs to the object at ffff8881298d9400 | which belongs to the cache kmalloc-512 of size 512 | The buggy address is located 336 bytes inside of | freed 512-byte region [ffff8881298d9400, ffff8881298d9600) Fix it by having chan->conn hold a reference to l2cap_conn (via l2cap_conn_get) when the channel is added to the connection, and releasing it in the channel destructor. This ensures the l2cap_conn remains alive as long as the channel exists. A new FLAG_DEL channel flag is introduced to indicate that the channel has been deleted from its connection. l2cap_chan_del() atomically sets this flag using test_and_set_bit() instead of setting chan->conn to NULL. All asynchronous workers (l2cap_chan_timeout, l2cap_ack_timeout, l2cap_monitor_timeout, l2cap_retrans_timeout) and l2cap_chan_send() check FLAG_DEL to determine whether the channel has been torn down, rather than testing chan->conn for NULL. Fixes: 8c8e620467a7 ("Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()") Cc: <stable@vger.kernel.org> Cc: Siwei Zhang <oss@fourdim.xyz> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Assisted-by: Gemini:gemini-3.1-pro-preview Reported-by: https://sashiko.dev/#/patchset/20260521021249.3258069-1-oss%40fourdim.xyz Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: btintel_pcie: Load IOSF debug regs by controller variantSai Teja Aluvala
Load the IOSF DBGC base address based on the controller hardware variant when reading DRAM buffers during a trace dump. Scorpius Peak family controllers (SCP/SCP2/SCP2F) use a different DBGC base address (0xf0d5d500) than Blazar family controllers (BZRI/BZRIW, 0xf3800300). Fixes: 07e6bddb54b4 ("Bluetooth: btintel_pcie: Add support for device coredump") Signed-off-by: Sai Teja Aluvala <aluvala.sai.teja@intel.com> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: btintel_pcie: Add 50 ms delay before MAC init on BlazarIWKiran K
On BlazarIW, fast restart cycles fail because the D0 entry to MAC init does not complete in time. As a result, MAC initialization does not proceed and the controller fails to transition past the ROM boot stage. Add a 50 ms delay (worst case as per HW analysis) before doing MAC init in btintel_pcie_enable_bt() so the shared hardware reset flow has time to complete. The delay is gated on the BlazarIW PCI device id 0x4D76 so other Intel BT PCIe controllers are unaffected. Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: Add SPDX id lines to some source filesTim Bird
Many bluetooth source files are missing SPDX-License-Identifier lines. Add appropriate IDs to these files, and remove other license lines from the headers. Leave the warranty disclaimer in files where the license ID is GPL-2.0 but the wording of the disclaimer is slightly different from that of the GPL v2 disclaimer. It is not different enough to cause licensing conflicts, but is kept to honor the original contributors' legal intent. Signed-off-by: Tim Bird <tim.bird@sony.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: btintel_pcie: Add support for smart trigger dumpKiran K
Based on the debug configuration, firmware can raise MSI-X interrupt with firmware trigger cause bit set on specific events like Disconnection, Connection Timeout, Page Timeout etc. Upon receiving an MSI-X interrupt with the firmware trigger cause bit set, the driver performs the following actions: 1. Reads Device Memory: Retrieves data from the device memory, constructs an HCI diagnostic event, and sends it to the monitor. This event includes details about the trigger, such as connection timeout or page timeout. 2. Dumps Device Coredump: Generates a coredump containing firmware traces for further analysis. The coredump can be retrieved using: $ cat /sys/class/devcoredump/devcd*/data > /tmp/btintel_coredump.bin HCI traces: = Vendor Diagnostic (len 12) a5 a5 a5 a5 01 03 00 23 00 01 00 00 Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: hci_h5: reset hci_uart::priv in the close() methodSergey Shtylyov
Unlike the other HCI UART drivers, the 3-wire UART driver doesn't reset hci_uart::priv in its close() method -- this shouldn't pose a problem as all the methods in *struct* hci_uart_proto should only be called after the open() method that sets up hci_uart::priv properly. However, it seems wise to be more consistent and provide for the *struct* hci_uart_proto methods the same state that exists before the first open() method call (so that they rather crash than dereference a stale hci_uart::priv pointer)... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Signed-off-by: Sergey Shtylyov <s.shtylyov@auroraos.dev> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: btusb: clean up probe error handlingJohan Hovold
Clean up probe error handling by using dedicated error labels with an "err" prefix. Note that the endpoint lookup helper returns -ENXIO when endpoints are missing which is functionally equivalent to returning -ENODEV. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: btusb: fix wakeup irq devres lifetimeJohan Hovold
The OOB wakeup interrupt is device managed but its lifetime is incorrectly tied to the child HCI device rather than the USB interface to which the driver is bound. This should not cause any trouble currently as the interrupt will be disabled when the HCI device is deregistered on disconnect (but this was not always the case, see [1]), and there should be no further references if probe fails before registering it. But it is still technically wrong as the reference counted HCI device could in theory remain after a probe failure. Explicitly free the interrupt on disconnect so that it is guaranteed to be disabled before freeing the (non-managed) driver data (including if disconnected while suspended). [1] 699fb50d9903 ("drivers: base: Free devm resources when unregistering a device") Fixes: fd913ef7ce61 ("Bluetooth: btusb: Add out-of-band wakeup support") Cc: Rajat Jain <rajatja@google.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: btusb: fix wakeup source leak on probe failureJohan Hovold
Make sure to disable wakeup on probe failure to avoid leaking the wakeup source. Fixes: fd913ef7ce61 ("Bluetooth: btusb: Add out-of-band wakeup support") Cc: stable@vger.kernel.org # 4.11 Cc: Rajat Jain <rajatja@google.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: btusb: fix use-after-free on marvell probe failureJohan Hovold
Make sure to stop any TX URBs submitted during Marvell OOB wakeup configuration on later probe failures to avoid use-after-free in the completion callback. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths. Link: https://sashiko.dev/#/patchset/20260402092704.2346710-1-johan%40kernel.org Fixes: a4ccc9e33d2f ("Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup") Cc: stable@vger.kernel.org # 4.11 Cc: Rajat Jain <rajatja@google.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: btusb: fix use-after-free on registration failureJohan Hovold
Make sure to release the sibling interfaces in case controller registration fails to avoid use-after-free and double-free when they are eventually disconnected. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths. Link: https://sashiko.dev/#/patchset/20260402092704.2346710-1-johan%40kernel.org Fixes: 9bfa35fe422c ("[Bluetooth] Add SCO support to btusb driver") Fixes: 9d08f50401ac ("Bluetooth: btusb: Add support for Broadcom LM_DIAG interface") Cc: stable@vger.kernel.org # 2.6.27 Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error pathZhao Dongdong
When btmtk_isopkt_pad() fails, the previously allocated URB is not freed, leaking the urb structure. Add usb_free_urb() before returning the error. Fixes: ceac1cb0259d ("Bluetooth: btusb: mediatek: add ISO data transmission functions") Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-06-11Bluetooth: hci_core: Fix UAF in hci_unregister_dev()Jordan Walters
hci_unregister_dev() does not disable cmd_timer and ncmd_timer before the hci_dev structure is freed. If a timeout fires during device teardown, the callback dereferences freed memory (including the hdev->reset function pointer), leading to a use-after-free. Add disable_delayed_work_sync() calls alongside the existing disable_work_sync() calls to ensure both timers are fully quiesced before teardown proceeds. Fixes: 0d151a103775 ("Bluetooth: hci_core: cancel all works upon hci_unregister_dev()") Signed-off-by: Jordan Walters <jaggyaur@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-07-17 19:32:44 +0000