summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-10-15Merge tag 'timers-v7.4-rc1' of ↵Thomas Gleixner
git://git.kernel.org/pub/scm/linux/kernel/git/daniel.lezcano/linux into timers/clocksource Pull clocksource/event driver updates from Daniel Lezcano: - Added support for the Renesas RZ/N1 timers, including DT bindings and a MAINTAINERS entry (Herve Codina) - Simplified per-CPU clock-event programming in the MIPS GIC timer driver (Benoît Monin) - Synchronized MIPS GIC counters across clusters to allow local counter reads, enable VDSO timekeeping and improve sched_clock precision (Benoît Monin) - Restricted clocksource and clock-event registration in the TI DM platform driver to AM654, fixing boot regressions on older OMAP platforms (Markus Schneider-Pargmann) - Checked timer register mapping failures in the DBX500 PRCMU driver (Slavin Liu) - Fixed clock reference leaks in the FTTMR010, Digicolor and EcoNet EN751221 timer drivers (Wentao Liang) - Fixed a boot-time crash in the MediaTek timer driver by enabling interrupts only after clock-event initialization (Luca Leonardo Scorcia) - Converted the MediaTek timer driver to OF platform probing to handle deferred clock availability (Luca Leonardo Scorcia) - Requested and enabled the optional bus clock for MediaTek APXGPT timers (Luca Leonardo Scorcia) - Handled runtime resume failures before accessing the TI DM timer counter register (Jiale Yao) Link: https://lore.kernel.org/all/61fe27a6-d19b-4f5b-b193-77d85ee64dc7@oss.qualcomm.com
2026-10-15IB/rdmavt: Fix error unwind path for qp_priv_init() in rvt_create_qp()Serhat Kumral
If driver_f.qp_priv_init() fails, execution jumps to bail_rq_wq, which bypasses bail_qpn. Because alloc_qpn() has already succeeded at this point, the allocated QP number is left unreleased. Jump to bail_qpn instead to ensure the QPN is properly freed via rvt_free_qpn(). Fixes: 5190f052a3654 ("IB/hfi1: Allow the driver to initialize QP priv struct") Signed-off-by: Serhat Kumral <serhatkumral1@gmail.com> Link: https://patch.msgid.link/20261015102518.15780-1-serhatkumral1@gmail.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-10-15of: overlay: remove unused of_overlay_remove_all()Abdurrahman Hussain
of_overlay_remove_all() has no in-tree callers. It is also subtly broken. It passes &ovcs->id to of_overlay_remove(), which zeroes *ovcs_id once the changeset is reverted, before calling free_overlay_changeset(). Through the aliased pointer that zeroes ovcs->id itself, so free_overlay_changeset()'s "ovcs->id > 0" guard is false and both idr_remove() and list_del() are skipped: the overlay_changeset is kfree()d while still linked in ovcs_list and registered in ovcs_idr. Rather than fix a helper nobody calls, remove it, along with its !CONFIG_OF_OVERLAY stub and the paragraph documenting it in overlay-notes.rst and in the zh_CN translation. ovcs_list itself stays: overlay_removal_is_ok() still walks it to check that a changeset is topmost. Reported-by: Sashiko AI <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/20260901014554.83A8D1F000E9@smtp.kernel.org Suggested-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/all/20260928182658.GA185307-robh@kernel.org/ Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai> Link: https://patch.msgid.link/20261014-b4-of-overlay-remove-all-fix-v2-1-cf5ea2cc9dc3@nexthop.ai Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-10-15spi: bcm-qspi: reject oversized dummy bytes in mspi exec_mem_opWeibin Liu
bcm_qspi_mspi_exec_mem_op() builds a local command buffer cmd[6] holding one opcode byte, up to four address bytes and one spare byte, and sets t[0].len = op->addr.nbytes + op->dummy.nbytes + 1. bcm_qspi_exec_mem_op() only validates op->addr.nbytes <= 4 and never bounds op->dummy.nbytes, which spi_mem_check_op() also leaves unrestricted. With addr.nbytes = 4 and dummy.nbytes >= 2 the length becomes 7 or more, so write_to_hw() reads past cmd[] on the kernel stack and pushes the leaked bytes into the hardware TXRAM. Reject operations whose dummy phase does not fit the remaining byte of cmd[] by requiring op->dummy.nbytes <= 1, so such transfers fall back to the generic SPI path instead of overrunning the buffer. Reviewed-by: Guanglei Zhu <zhugl3@xiaopeng.com> Fixes: 5f195ee7d830c ("spi: bcm-qspi: Implement the spi_mem interface") Cc: stable@vger.kernel.org # 4.18+ Signed-off-by: Weibin Liu <liuwb@xiaopeng.com> Link: https://patch.msgid.link/20261015-bcm-qspi-dummy-bytes-v1-1-c319da3c2497@xiaopeng.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-10-15Merge branch 'for-next/fw-rmi' into for-next/coreCatalin Marinas
* for-next/fw-rmi: : RMM v2.0 base RMI support firmware: arm_rmm: hotplug: Skip memory added to ZONE_MOVABLE firmware: arm_rmm: Add wrappers for Realm related RMI commands arm64: Block hibernate and kexec while RMM is active PM: hibernate: Add an arch hook for preventing hibernation firmware: arm_rmm: Ensure the RMM has GPT entries for memory firmware: arm_rmm: Activate the RMM firmware: arm_rmm: Add support for SRO firmware: arm_rmm: Configure the RMM with the host's page size firmware: arm_rmm: Check for RMI support at init firmware: arm_rmm: Add SMC definitions for calling the RMM arm64: mm: Handle Granule Protection Faults (GPFs)
2026-10-15Merge branches 'for-next/misc', 'for-next/be-gone', 'for-next/smccc-bus', ↵Catalin Marinas
'for-next/preemptible-this-cpu', 'for-next/cpu-errata', 'for-next/mpam', 'for-next/kselftest', 'for-next/efi', 'for-next/secondary-boot-prep', 'for-next/sysreg' and 'for-next/gcs', remote-tracking branch 'arm64/for-next/perf' into for-next/core * arm64/for-next/perf: (22 commits) drivers/perf: apple_m1: Add macOS 27 M2 Event perf/marvell: cn10k_tad: Publish the OF module alias perf: xgene: initialize lock before requesting IRQ perf: marvell: avoid large stack variables perf/dwc_pcie: Fix PCI device reference leak in probe coresight: perf: Suppress ITRACE start records perf: arm_spe: Suppress redundant ITRACE start records perf/core: Export perf_event_itrace_started() perf/cxl: Clear stale overflow status before using a counter perf/cxl: Don't log through pmu.dev in the overflow interrupt handler perf/cxl: Validate the hardware-reported counter width perf/cxl: Unfreeze counters after handling an overflow interrupt perf/cxl: Don't share the overflow interrupt, and keep it pinned cxl/pci: Add the PMUs after configuring events perf/cxl: Split the MSI vector out of info->irq perf/cxl: Accept an overflow interrupt on MSI message number 0 perf/cxl: Fix the counter overflow delta fixup perf/cxl: Clear stale event fields before reprogramming a counter perf/cxl: Program the requested event group on configurable counters drivers/perf: hisi: Add cycle event for new MN PMU ... * for-next/misc: arm64: cpufeature: Enable BBML2 for NVIDIA Rigel arm64: cputype: Add NVIDIA Rigel definitions arm64: raise default ARCH_MMAP_RND_BITS for 48-bit and 52-bit VA arm64/debug: mask debug exceptions when called from common code arm64: clear_page[s] using memset arm64/sve: Don't zero the SVE state buffer when the SVE state is live arm64/cpufeature: Drop redundant define(ID_AA64MMFR0..._SUPPORTED_LPA2) arm64: Use proper include variant arm64: include: fix repeated word 'to' in comment selftests: arm64: fix typo "hander" in comment arm64: fix typos in comments docs: arm64: Fix typo "initalised" in booting.rst arm64: alternative: Remove 'cfg' parameter arm64: mte-kasan: Use IS_ENABLED() rather than ALTERNATIVE() 'cfg' parameter arm64/cpufeature: Change description for ARM64_HAS_LPA2 * for-next/be-gone: drivers: Kconfig: Simplify dependencies on ARM64 && !CPU_BIG_ENDIAN arm64: Kbuild: Remove vestigial big-endian support gve: Add explicit ARM64 dependency to Kconfig crypto: hisilicon/sec2: Remove check of CONFIG_CPU_LITTLE_ENDIAN arm64: Remove all usage of __AARCH64EB__ arm64: Remove all usage of CONFIG_CPU_BIG_ENDIAN KVM: arm64: Remove support for a big-endian hypervisor object arm64: vdso32: Always build compat vDSO object as little-endian arm64: assembler: Remove endianness helper macros arm64: lib: Assume a little-endian kernel in optimised string routines arm64: lib: Assume a little-endian kernel in custom library routines arm64: crypto: Assume a little-endian kernel arm64: bpf: Remove big-endian support from the JIT compiler selftests/arm64: Remove big-endian support * for-next/smccc-bus: : Switch Arm SMCCC firmware services to an SMCCC bus arm64: rsi: Correct type of realm_config::hash_algo firmware: smccc: Pass only the required device probe arguments firmware: arm_rmm: Add SPDX and sort the Kconfig and Makefile entries coco: guest: arm64: Remove dummy CCA platform device coco: guest: arm64: Add sysfs ABI for CCA Realm guests firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device virt: coco: arm-cca-guest: Rename TSM report source file arm64: realm: Move Realm memory encryption ops to RSI code firmware: arm_rmm: Move RSI support out of arch/arm64 firmware: hwrng: arm_smccc_trng: Register as an SMCCC device firmware: smccc: Add an Arm SMCCC bus * for-next/preemptible-this-cpu: : Preemptible this_cpu_*() operations arm64: percpu: Remove _pcp_protect*() wrappers arm64: percpu: Implement preemptible CMPXCHG128 ops arm64: percpu: Implement preemptible CMPXCHG ops arm64: percpu: Implement preemptible XCHG ops arm64: percpu: Implement preemptible return RMW ops arm64: percpu: Implement preemptible void RMW ops arm64: percpu: Implement preemptible read/write ops arm64: percpu: Add infrastructure for preemptible this_cpu_*() ops arm64: entry: sdei: Make 'tsk' available arm64: entry: sdei: Restore all clobberable GPRs arm64: gpr-num: add __GPR_NUM() helper arm64: gpr-num: Add wxN aliases for wN registers arm64: percpu: Factor out percpu offset asm arm64: ptrace: Always inline pt_regs_{read,write}_reg() arm64: preempt: Treat should_resched() as unlikely arm64: preempt: Simplify and optimize __preempt_count_dec_and_test() arm64: cmpxchg128: LSE: Remove redundant operands arm64: cmpxchg: LL/SC: Avoid redundant extension * for-next/cpu-errata: : Various CPU errata workarounds arm64: errata: Add NXP i.MX8QM/8QP workaround for A53 cache coherency issue arm64: cpufeature: Add ARM64_CPUCAP_SOC_ERRATUM for SoC-level errata * for-next/mpam: (30 commits) : MPAM updates arm_mpam: make the mon_sel guard conditional only arm_mpam: On saving mbwu state read the monitors before clearing CFG_MBWU_CTL arm_mpam: detect and enable MPAM-Fb PCC support arm_mpam: change MPAM-Fb error IRQ to use a threaded IRQ handler arm_mpam: add MPAM-Fb MSC firmware access support arm_mpam: prepare mon_sel locking for MPAM-Fb arm_mpam: propagate MSC access errors in mpam_reset_class_locked() arm_mpam: propagate MSC access errors for interrupt control arm_mpam: propagate MSC access errors for mpam_reprogram_ris_partid() arm_mpam: propagate MSC access errors for state saving function arm_mpam: propagate MSC access errors for __ris_msmon_read() arm_mpam: propagate MSC access errors for msmon helpers arm_mpam: propagate MSC access errors for MBWU counters arm_mpam: propagate MSC access errors for hw_probe functions arm_mpam: let low level MSC accessors return an error MAINTAINERS: Use linux-arm-kernel list for the MPAM driver MAINTAINERS: Add mpam.rst to the MPAM DRIVER entry arm_mpam: resctrl: Don't stop early when tearing down a class arm_mpam: Switch to kvzmalloc_objs() for allocation of component cfg arm_mpam: Don't loop forever if there is the maximum possible amount of PARTIDs ... * for-next/kselftest: : arm64 kselftest updates kselftest/arm64: signal: copy each test binary only once kselftest/arm64/mte: Use MTE safe memory accessors kselftest/arm64/mte: Introduce MTE safe memory accessors kselftest/arm64: Extend gcs-locking to cover cases where enable is unlocked * for-next/efi: : arm64 EFI updates/fixes arm64/mm: Treat faults taken by EFI runtime firmware as kernel faults arm64/efi: Clear PTE_WRITE when applying EFI_MEMORY_RO * for-next/secondary-boot-prep: : cpuinfo cleanup in preparation for parallel secondary bring-up arm64: smp: Defer RCU registration during secondary CPU bringup arm64: smp: Don't bother printing the I-cache policy for each CPU arm64: smp: Defer update of secondary CPU capabilities arm64: smp: Tidy up cpuinfo init and cpufeature updates arm64: smp: Tidy up smp_prepare_cpus() arm64: cpufeature: Store every ID register with its overrides applied arm64: cpufeature: Read MPAMIDR_EL1 in __cpuinfo_store_cpu() arm64: cpufeature: Add read_cpuid_with_overrides() arm64: cpufeature: Check arm64_ftr_regs[] before the first store * for-next/sysreg: : sysreg updates perf: arm_brbe: Remove the check for TME transaction states arm64: sysreg: Mark fields the architecture dropped as RES0 arm64: sysreg: Fix the names of two misspelt fields arm64: sysreg: Fix three incorrect enum values * for-next/gcs: : GCS updates/fixes kselftest/arm64: Check for -EPERM not -EBUSY in the locking test arm64: gcs: Return -EPERM not -EBUSY for prctl() locking failures
2026-10-15arm64: cpufeature: Enable BBML2 for NVIDIA RigelShanker Donthineni
The BBML2 no-abort capability is an allow-list of CPUs that support BBML2 and do not raise TLB conflict aborts for mapping granularity changes. Add the NVIDIA Rigel core to that allow-list. Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-10-15arm64: cputype: Add NVIDIA Rigel definitionsShanker Donthineni
Add CPU part and model macro definitions for the NVIDIA Rigel core. Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-10-15arm64: raise default ARCH_MMAP_RND_BITS for 48-bit and 52-bit VAIurii Trukhin
Since commit f101c5644771 ("arm64: Support ARM64_VA_BITS=52 when setting ARCH_MMAP_RND_BITS_MAX"), arm64 supports up to 33, 31, and 29 bits of mmap ASLR entropy on 48-bit and 52-bit virtual address spaces for 4K, 16K, and 64K pages respectively. However, ARCH_MMAP_RND_BITS still defaults to ARCH_MMAP_RND_BITS_MIN (18, 16, and 14 bits), which was set in commit 8f0d3aa9de57 ("arm64: mm: support ARCH_MMAP_RND_BITS") when 39-bit VA was the 4K default. Set the default ARCH_MMAP_RND_BITS for 48-bit and 52-bit VA to 28 (4K pages), 26 (16K pages), and 24 (64K pages), matching x86_64's 1 TiB randomization range (5 bits below ARCH_MMAP_RND_BITS_MAX) while keeping ARCH_MMAP_RND_BITS_MIN unchanged for smaller VA configurations. Closes: https://github.com/KSPP/linux/issues/371 Reviewed-by: Kees Cook <kees@kernel.org> Signed-off-by: Iurii Trukhin <yuri@trukhin.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-10-15arm64/debug: mask debug exceptions when called from common codeAda Couprie Diaz
We can currently take debug exceptions while manipulating the hardware breakpoint registers and perf slots when called from generic kernel code. This can lead to errors and unsound behaviours in some pathological (and self-inflicted) edge cases[0]. Save and restore the DAIF mask around those manipulations. This is to avoid a superfluous save/restore when calling `toggle_bp_registers()` and `hw_breakpoint_control()` from our arch code, as debug exceptions will already be masked in all cases. It should also allow some clean ups by batching ISBs when we update multiple registers, rather than doing one for each register write. Clarify some comments and specify a few functions which should be called with debug exceptions masked (even though that is true for most of them). [0]: https://lore.kernel.org/linux-arm-kernel/adeE4MD0RgapI8aL@J2N7QTR9R3/ Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-10-15kselftest/arm64: signal: copy each test binary only onceSasha Levin
The signal tests are built in testcases/ and then copied to the output directory. The copy rule lists every generated program as a target and copies all of them in each recipe: $(TEST_GEN_PROGS): $(PROGS) cp $(PROGS) $(OUTPUT)/ In a parallel build make runs that recipe once for each program, so several cp processes write the same destination files at the same time. cp then fails with "cannot create regular file ...: File exists", which fails the arm64 build even though every test compiled. A cross build of the arm64 signal tests at -j8 hit this in all of 8 runs. Use a static pattern rule so that each output depends on, and copies, only its own binary. Fixes: f96bf4340316 ("kselftest: arm64: mangle_pstate_invalid_compat_toggle and common utils") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-10-15iommupt: Do not allow PTEs to be split when dirty loggingJason Gunthorpe
If a single PTE cannot be stored in the current bitmap that should be a failure and reported back to userspace. Allowing a PTE to be split creates a possibility that dirty memory will be reported as clean. The gather must also cover the entire PTE that is being cleaned, not just the part that fits within the bitmap. Fix both issues by computing the full IOVA range of every PTE and using that to update the bitmap and the gather. The bitmap code now rejects ranges that don't fit in it, and the gather always combined ranges. The selftest quietly relied on a bug where the CONT was split, that is why the half page size for the mock domain saw alternating dirties. Increase the dirty test page size to PAGE_SIZE so it still works as intended. Cc: stable@vger.kernel.org Fixes: 4a00f9434891 ("iommupt: Add read_and_clear_dirty op") Reported-by: Samarth Narang <samarth.colleges@gmail.com> Closes: https://lore.kernel.org/all/20261013165814.309255 Link: https://patch.msgid.link/r/0-v1-5bb926ff73ec+576-iommufd_dirty_jgg@nvidia.com Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-10-15iommufd/iova_bitmap: Ensure that iova_bitmap_set() handles the full IOVAAndrea Parri
Generally userspace is going to step the dirty bitmap through the IOVA space. However if the bitmap ends in the middle of a large PTE this is problematic. The first step will clear the dirty bit and report dirty to the end of its bitmap while the second step will see the clear'd dirty and report clean for the start of the bitmap. If it happens this ends up losing dirties. Further this function is missing bounds checking so if this does happen ther is a good chance it will write memory beyond what the userspace was expecting. Return an error code if this illegal condition happens. Fixes: 58ccf0190d19 ("vfio: Add an IOVA bitmap support") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Andrea Parri <parri.andrea@gmail.com> Link: https://patch.msgid.link/20260925161142.189813-2-parri.andrea@gmail.com Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-10-15selftests/bpf: Accept unnamed dma-bufs in the dmabuf_iter default testQiliang Yuan
The dmabuf_collector iterator prints the inode, size, name and exporter of every dma-buf in the system on separate lines, with an empty name for the buffers that have none. The default_iter subtest parses that output and looks for the two buffers it created. It requires a name for every buffer, and sscanf() finds none on the empty line of an unnamed one. On a system that has such a buffer, like one exported by udmabuf without a name, the subtest fails before it gets to its own buffers. Take an empty name for a buffer without one. Fixes: ae5d2c59ecd7 ("selftests/bpf: Add test for dmabuf_iter") Signed-off-by: Qiliang Yuan <odys.yuan@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: T.J. Mercier <tjmercier@google.com> Link: https://lore.kernel.org/bpf/20261009-selftests-bpf-dmabuf-iter-unnamed-v1-1-962ee94f7a5e@gmail.com
2026-10-15drm/amdgpu/sdma3: Work around POLL_REGMEM / FENCE hangTimur Kristóf
SDMA can randomly hang on Polaris 10. Hard to reproduce, but has been occurring sporadically in the Mesa CI on the RADV Polaris 10 job even when Mesa isn't using the SDMA engine. When Mesa actually uses the SDMA on Polaris, the hang becomes more frequent and the reproduction rate goes up significantly in the CI system. We don't know why the hangs occur, but it seems that inserting a single NOP packet before each POLL_REGMEM and FENCE packet works around it. At the moment it's unclear which GPUs are affected, so let's apply this to SDMA 3.x for now. Note that this issue is not documented or acknowledged by AMD. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c343a27ed90823d08de125f7c447d96d056b75d9) Cc: stable@vger.kernel.org
2026-10-15drm/amdgpu: keep the eviction fence until the last handle is closedJesse Zhang
amdgpu_gem_object_close() detaches the user queue eviction fence from the BO before it checks bo_va->ref_count, so closing any handle of a BO removes the fence, even when the file still has another handle to the BO and the bo_va with its GPU mappings stays. The BO can then be evicted without suspending the user queues of the file, which keep accessing it through mappings that are only marked for update. Seen on navi31 with a SDMA user queue: a BO opened twice in the same file (GEM_FLINK + GEM_OPEN) loses its eviction fence when the second handle is closed (traced attach/detach of the fence): attach bo=ffff8c78a6c84c00 GEM_CLOSE handle=7 detach bo=ffff8c78a6c84c00 while handle 6 and the mapping are still in use. Only detach the fence when the last reference to the bo_va goes away, matching amdgpu_gem_object_open(), which attaches it only when the bo_va is created. With this the fence stays until the file is closed. Fixes: 31f7efcdca4d ("drm/amdgpu: enable eviction fence") Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8387982f03d4026b7dc11b0b5e3118298eee4d6a) Cc: stable@vger.kernel.org
2026-10-15drm/amd/display: Fix NULL sink dereference in USB4 bandwidth functionsSrinivasan Shanmugam
allocate_usb4_bandwidth_for_stream() and allocate_usb4_bandwidth() both use ASSERT(stream->sink) before dereferencing stream->sink->link. ASSERT is compiled out in production builds, so a NULL stream->sink causes a NULL pointer dereference. link_set_dpms_off() already guards two earlier accesses to stream->sink with explicit NULL checks, confirming that stream->sink can legitimately be NULL. The subsequent call to deallocate_usb4_bandwidth() had no equivalent guard. Replace the ASSERT() calls with proper NULL checks that return false early, and add a matching stream->sink guard at the call site in link_set_dpms_off() consistent with the surrounding pattern. v2: Keep the existing ASSERT() calls for diagnostics (to report unexpected NULL sink), and add explicit NULL checks that return false before dereferencing stream->sink. Also add a matching stream->sink guard at the deallocation call site in link_set_dpms_off(). (Alex) Fixes: 8fa813b7fd1e ("drm/amd/display: Remove sink usage from DPMS") Reported-by: Dan Carpenter <error27@gmail.com> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Dominik Kaszewski <dominik.kaszewski@amd.com> Cc: George Zhang <george.zhang@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Roman Li <Roman.Li@amd.com> Cc: Ivan Lipski <ivan.lipski@amd.com> Cc: Dan Wheeler <daniel.wheeler@amd.com> Cc: Alex Hung <alex.hung@amd.com> Cc: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 98029a0ce61feb52c563f65349dd9b25f672e355) Cc: stable@vger.kernel.org
2026-10-15drm/amdgpu/userq: actually validate userq BOsBenjamin Cheng
This was supposed to loop over the individual evicted list, as the kernel and always_valid evicted lists were already handled in amdgpu_vm_validate. Without this, BOs that were created and evicted before a userq was made would never end up in an eviction fence rearm. Also add the missing ref to the BO before drm_exec locks and refs it. Fixes: 4cdbba5a16aa ("drm/amdgpu: restructure VM state machine v4") Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 18decfc9e8cc0fa70b6de9944cc27a37729edfbd) Cc: stable@vger.kernel.org
2026-10-15drm/amdgpu: report the BO alignment in bytes in GEM_LIST_HANDLESJesse Zhang
The uapi documents drm_amdgpu_gem_list_handles_entry.alignment as "physical start_addr alignment in bytes", and GEM_OP GET_GEM_CREATE_INFO returns the same value in bytes, but GEM_LIST_HANDLES returns tbo.page_alignment, which is in pages. For a BO created with a 64 KiB alignment on navi31: GET_GEM_CREATE_INFO: alignment=65536 GEM_LIST_HANDLES: alignment=16 so a user such as CRIU that recreates BOs from this list uses the wrong alignment. Convert it to bytes. Fixes: f9db1fc52ceb ("drm/amdgpu: Add ioctl to get all gem handles for a process") Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit aa4493ae949c13e79aba0731394dd7a7e431342b) Cc: stable@vger.kernel.org
2026-10-15drm/amdgpu: free the userptr ranges when a CS fails after parser_bosJesse Zhang
amdgpu_cs_parser_bos() allocates an HMM range for every userptr entry of the BO list and looks up the user pages. Those ranges are only freed when amdgpu_cs_parser_bos() itself fails or when amdgpu_cs_submit() checks them under the notifier lock. If amdgpu_cs_patch_jobs(), amdgpu_cs_vm_handling(), amdgpu_cs_sync_rings() or the early part of amdgpu_cs_submit() fails, nothing frees them: neither amdgpu_cs_parser_fini() nor amdgpu_bo_list_free() touch e->range. Each such CS then leaks the range, its hmm_pfns array (8 bytes per page of the userptr BO) and the BO reference the range holds. An IB on a ring that patches the CS in place (e.g. VCN) with an unmapped va_start fails in amdgpu_cs_patch_ibs() and takes this path. Free the ranges on those error paths. Ranges amdgpu_cs_submit() already dropped are NULL, so freeing them again is a no-op. Fixes: fec8fdb54e8f ("drm/amdgpu: fix userptr HMM range handling v2") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c52a9542ed7cfd527feb938bd0accada2ac8d267) Cc: stable@vger.kernel.org
2026-10-15drm/amdgpu: don't drop the runtime PM reference twice in amdgpu_gprJesse Zhang
amdgpu_debugfs_gpr_read() drops its runtime PM reference right after reading the wave registers. When copying them to userspace fails, it jumps to the err label, which drops the reference a second time. A read into a bad buffer on Navi31 either steals a reference somebody else holds (power/runtime_usage goes from 1 to 0) or underflows the count: amdgpu 0000:03:00.0: Runtime PM usage count underflow! The registers are already in the kernel buffer at that point, so finish the hardware access first and copy the buffer with a single copy_to_user() instead of the put_user() loop with its own error path. Fixes: 9eee152aab56 ("drm/amdgpu/debugfs: fix ref count leak when pm_runtime_get_sync fails") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 31035bbd74f7c3e10c163db875b8e67f8b50ee6a) Cc: stable@vger.kernel.org
2026-10-15drm/amdgpu: fix GEM object leak on ENOMEM in userptr ioctlPerry Yuan
When amdgpu_hmm_range_alloc() fails amdgpu_gem_userptr_ioctl() returns -ENOMEM right away and skips the cleanup every other error path goes through. The GEM object, the bo->parent reference on the VM root and the MMU notifier registration are all left behind. Use release_object here, not user_pages_done, range is still NULL at this point. Fixes: e095b55155ef ("drm/amdgpu: use user provided hmm_range buffer in amdgpu_ttm_tt_get_user_pages") Signed-off-by: Perry Yuan <perry.yuan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit bbe739e407a542073ec1a7872b14843566b4919e) Cc: stable@vger.kernel.org
2026-10-15drm/amd/pm: add zero fan stop temperature support on smu 14.0.2Kenneth Feng
add zero fan stop temperature support on smu 14.0.2 Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5905 Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Kevin Wang <kevin.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f990c94a2633d0ead477eb1b174e254a6d292e66) Cc: stable@vger.kernel.org
2026-10-15drm/amdgpu: destroy mutex when tearing down ttm buffer entityPerry Yuan
Pair mutex_init() with mutex_destroy() on the GART window allocation failure path and in amdgpu_ttm_buffer_entity_fini(). This is a no-op without CONFIG_DEBUG_MUTEXES, but it keeps lockdep from seeing a live mutex after the entity is freed or re-initialized. Signed-off-by: Perry Yuan <perry.yuan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 03ac40aeed034a0a0d5824ad26f8fbe1f6463698) Cc: stable@vger.kernel.org
2026-10-15drm/amdgpu: fix sched entity leak in ttm buffer entity initPerry Yuan
amdgpu_ttm_buffer_entity_init() checks num_gart_windows after drm_sched_entity_init() has already attached the entity to a scheduler run-queue. Returning -EINVAL from that check leaks the entity. Move the ARRAY_SIZE() check before any resources are acquired. Fixes: 2c3725572561 ("drm/amdgpu: statically assign gart windows to ttm entities") Signed-off-by: Perry Yuan <perry.yuan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 4000d1cdd1eacd3422267d6c8b4f1c9333b0317e) Cc: stable@vger.kernel.org
2026-10-15drm/amdgpu/uvd3.1: Fix checking whether UVD firmware keyselect was already setTimur Kristóf
The PASS_MASK is for a different register not for UVD_FW_START. It was a mistake to check this flag. It should be enough to check that the register is non-zero. Fixes: 889a2cfd889c ("drm/amdgpu/uvd3.1: Don't validate the firmware when already validated") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20261006211607.75407-1-timur.kristof@gmail.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 9dee462c83259ca769aa1bf82228adee9831685c) Cc: stable@vger.kernel.org
2026-10-15selftests/bpf: Fix map fd leak in no-BTF wq testYun Lu
bpf_map__reuse_fd() duplicates the supplied file descriptor instead of taking ownership of it. test_failure_map_no_btf() closes the original map_fd only when reuse fails, leaking it when reuse succeeds, including when the test passes. Destroying the skeleton closes its own descriptor but leaves the original descriptor and its map reference alive. Close map_fd immediately after bpf_map__reuse_fd(), before checking its return value, to release the original descriptor on both success and failure. The skeleton retains its own descriptor for the subsequent program load. Fixes: bca2b74ea9a8 ("selftests/bpf: Add more bpf_wq tests") Reported-by: Jackie Liu <liuyun01@kylinos.cn> Signed-off-by: Yun Lu <luyun@kylinos.cn> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20261013030114.292157-1-luyun_611@163.com
2026-10-15HID: roccat: fix device access in roccat_release()Dmitry Antipov
In roccat_release(), access the device using file-specific reader data rather than global array, thus preventing the case when original device was disconnected and a new device has connected using the same slot indexed by minor number. Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://sashiko.dev/#/patchset/20260902094551.200587-1-dmantipov@yandex.ru?part=2 Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2026-10-15ALSA: core: Serialize snd_refcount put and syncTakashi Iwai
When a thread tries to sync-and-destroy the resource with snd_refcount_sync(), it might lead to a UAF in a very slight time window. Namely, snd_refount_put() calls wake_up() after atomic_dec_and_test(), but wait_event() in snd_refcount_sync() checks the condition via atomic_test() without serialization, hence the thread that called snd_refcount_sync() can continue immediately to release the resource before another thread calls wake_up(). For avoiding the race above, introduce the spinlock and take it at snd_refcount_put() and snd_refcount_sync() in order to serialize the operations. Fixes: dcca9b6064c3 ("ALSA: Add simple refcount helper functions") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20261015071838.31082-1-tiwai%40suse.de Reviewed-by: Cen Zhang <zzzccc427@gmail.com> Link: https://patch.msgid.link/20261015112256.3902-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-10-15Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.3-rc8). No conflicts. Adjacent changes: drivers/net/ethernet/microchip/lan865x/lan865x.c 2a3f6d2a9ac3 ("microchip: lan865x: move setting of netops to fix crash") 15358c2c3dca ("net: ethernet: oa_tc6: return ERR_PTR from oa_tc6_init()") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-10-15MAINTAINERS: add Neill Kapron as USB Gadget maintainerNeill Kapron
Restore the USB GADGET/PERIPHERAL SUBSYSTEM entry and add myself as maintainer to help review and maintain USB gadget drivers, core framework, headers, and documentation. Signed-off-by: Neill Kapron <nkapron@google.com> Link: https://patch.msgid.link/20261015152458.3541767-1-nkapron@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-15selftests/bpf: Create the vxlan devices of test_tunnel with their MACQiliang Yuan
The vxlan tests of test_tunnel create a tunnel device in the initial netns with "ip link add", and then give it the MAC address that the static neighbor entry at the other end points to with "ip link set". systemd-udevd assigns new devices of the initial netns a MAC address of its own, following its MACAddressPolicy, when it handles their uevent. When it gets to that after the test set the address, the replies sent to the configured MAC are dropped as meant for another host, and the ping of vxlan_tunnel fails after 10 seconds. Pass the address to "ip link add". udevd leaves alone the address of a device that was created with one. Fixes: 1ee7efd40abf ("selftests/bpf: Move vxlan tunnel testcases to test_progs") Signed-off-by: Qiliang Yuan <odys.yuan@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20261009-selftests-bpf-tunnel-vxlan-mac-v1-1-624dd769c334@gmail.com
2026-10-15USB: Documentation: Update description of completion callback contextAlan Stern
The existing kerneldoc documentation for URB completion callbacks is incorrect about the context in which the callbacks occur; it is not always in_interrupt. State explicitly that a callback may occur in any context with no guarantees, and likewise for the status of CPU-local interrupts. Documentation update only; no code changes. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://patch.msgid.link/de582feb-a0aa-4fc8-9818-890014de32a9@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-15selftests/bpf: Clean up sa_family_t-stringifierMichal Luczaj
Following commit f3de1cf621f7 ("selftests/bpf: sockmap_listen cleanup: Drop af_unix redir tests") and commit 9266e49d608c ("selftests/bpf: sockmap_listen cleanup: Drop af_vsock redir tests"), sockmap_listen.c: family_str() becomes functionally identical to select_reuseport.c: family_str(). Move the logic to socket_helpers.h. Suggested-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Michal Luczaj <mhal@rbox.co> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://msgid.link/CAAVpQUDULzZh58oKkRaYqgM9bRToGb7wHrzT+cZNpRmAtM12Ow@mail.gmail.com Link: https://lore.kernel.org/bpf/20261008-selftests-sockmap_listen-cleanup-v1-1-f6d1a4ff540d@rbox.co
2026-10-15HID: roccat: savu: reject short special reportsJiale Yao
The raw event callback runs before HID core validates and zero-pads the report. It passes the buffer to a helper which inspects data[0] and, for a special report, reads the complete struct savu_mouse_report_special. A truncated report can therefore cause an out-of-bounds read. Require enough data for the special report before calling the helper. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: 6a2a6390cf09 ("HID: roccat: add support for Roccat Savu") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao <yaojiale02@163.com> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2026-10-15HID: roccat: ryos: reject short special reportsJiale Yao
The raw event callback runs before HID core validates and zero-pads the report. It reads the report number without checking the received length and passes matching data to roccat_report_event(), which copies a complete struct ryos_report_special. A truncated report can therefore cause an out-of-bounds read and expose adjacent data through the Roccat character device. Require a complete special report before inspecting or forwarding it. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: 6f3a19360545 ("HID: roccat: add support for Ryos MK keyboards") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao <yaojiale02@163.com> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2026-10-15HID: roccat: pyra: reject short button reportsJiale Yao
The raw event callback runs before HID core validates and zero-pads the report. It passes the buffer to helpers which inspect data[0] and read a complete struct pyra_mouse_event_button for button reports. A truncated report can therefore cause an out-of-bounds read. Require enough data for the button report before calling either helper. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: cb7cf3da0daa ("HID: roccat: add driver for Roccat Pyra mouse") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao <yaojiale02@163.com> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2026-10-15HID: roccat: kovaplus: reject short button reportsJiale Yao
The raw event callback runs before HID core validates and zero-pads the report. It passes the buffer to helpers which inspect data[0] and read a complete struct kovaplus_mouse_report_button for button reports. A truncated report can therefore cause an out-of-bounds read. Require enough data for the button report before calling either helper. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: 0e70f97f257e ("HID: roccat: Add support for Kova[+] mouse") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao <yaojiale02@163.com> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2026-10-15HID: roccat: konepure: reject short button reportsJiale Yao
The raw event callback runs before HID core validates and zero-pads the report. It reads the report number without checking the received length and passes matching data to roccat_report_event(), which copies a complete struct konepure_mouse_report_button. A truncated report can therefore cause an out-of-bounds read and expose adjacent data through the Roccat character device. Require a complete button report before inspecting or forwarding it. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: 8936aa31cd5f ("HID: roccat: add support for Roccat Kone Pure gaming mouse") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao <yaojiale02@163.com> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2026-10-15HID: roccat: koneplus: reject short button reportsJiale Yao
The raw event callback runs before HID core validates and zero-pads the report. It passes the buffer to helpers which inspect data[0] and, for a button report, read the complete struct koneplus_mouse_report_button. A truncated report can therefore cause an out-of-bounds read. Require enough data for the button report before calling either helper. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: 47dbdbffe15b ("HID: roccat: Add support for Roccat Kone[+] v2") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao <yaojiale02@163.com> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2026-10-15HID: roccat: isku: reject short button reportsJiale Yao
The raw event callback runs before HID core validates and zero-pads the report. It passes the buffer to helpers which inspect data[0] and, for a button report, read the complete struct isku_report_button. A truncated report can therefore cause an out-of-bounds read. Require enough data for the button report before calling either helper. Commit 47669bec44fe ("HID: asus: refactor the two workqueues and init sequence") added the same kind of raw-event length validation to hid-asus. Fixes: d41c2a7011df ("HID: roccat: Add support for Isku keyboard") Cc: stable@vger.kernel.org Signed-off-by: Jiale Yao <yaojiale02@163.com> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2026-10-15ASoC: qcom: qdsp6: report the position of a drained bufferMark Brown
Vladyslav Tymoshchuk <tvlad744@gmail.com> says: Since commit a93dad6f4e6a ("ASoC: q6apm-dai: make use of q6apm_get_hw_pointer") q6apm-dai reports one frame less than the position of the last buffer the DSP returned, and commit 44432315444c ("ASoC: qcom: q6asm-dai: use q6asm_get_hw_pointer") did the same in q6asm-dai. When the application stops feeding a playback stream, the position never reaches appl_ptr: ALSA never sees the underrun, the stream stays RUNNING without period interrupts, and drain ends on its timeout with -EIO. On a OnePlus Pad 3 (SM8750) this left PipeWire's PCM stuck for hours after a stall. Patch 1 wraps the q6apm position to 0 at the end of the ring, as before a93dad6f4e6a. Patch 2 resets the q6apm hw pointer on prepare, which a93dad6f4e6a also stopped doing. Patch 3 is patch 1 for q6asm-dai. Patches 1 and 2 are tested on SM8750 (numbers in patch 1). Patch 3 is compile-tested only; a test on a Q6ASM board (RB3, RB5) and on x1e or sc8280xp for patches 1 and 2 would be very welcome. The RFC "ASoC: qcom: q6apm: correct PCM formats and error handling" by Zhang Jiaxi [1] touches the same hw pointer, in graph_callback() (4/4 "recover PCM from failed data receipts"). The two do not conflict: that series changes when the hw pointer is published, this one how it is turned into a position and when it is reset, and that series applies on top of this one on sound/for-next without conflicts. The analysis, the patches and this text were drafted with an AI assistant (Claude, see Assisted-by); I reviewed them and ran the tests described in the patches. [1] https://lore.kernel.org/r/SY5PR01MB10600B2BE812BAA1B0FA501B4A1932@SY5PR01MB10600.ausprd01.prod.outlook.com Link: https://patch.msgid.link/20261014162703.10172-1-tvlad744@gmail.com
2026-10-15ASoC: qcom: q6asm-dai: wrap the position of a full ring to 0Vladyslav Tymoshchuk
Commit 44432315444c ("ASoC: qcom: q6asm-dai: use q6asm_get_hw_pointer") took the position from the number of period buffers the DSP has returned in the current lap, 1..periods, and reports one frame less than that, as q6apm-dai does. One frame short, a playback stream whose application stops feeding it never reaches the stop threshold: the DSP returns the last queued buffer, the position stops at appl_ptr - 1 and no period interrupt comes any more, so ALSA never detects the underrun, the stream stays RUNNING and drain only ends on its timeout. On capture, the last frame of each period is held back until the next one. Before that commit the position wrapped to 0 at the end of the ring. Do that again, as for q6apm-dai. Fixes: 44432315444c ("ASoC: qcom: q6asm-dai: use q6asm_get_hw_pointer") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Vladyslav Tymoshchuk <tvlad744@gmail.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20261014162703.10172-4-tvlad744@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-10-15ASoC: qcom: q6apm: reset the hw pointer with the fragment queueVladyslav Tymoshchuk
On every prepare in queue mode, q6apm_dai_prepare() frees and allocates the fragments again, and q6apm_alloc_fragments() resets dsp_buf, so the first buffer queued after it is the first one of the ring. The hw pointer that q6apm_dai_pointer() reports is left as it was. q6apm-dai used to keep its own position and cleared it in prepare. Since commit a93dad6f4e6a ("ASoC: q6apm-dai: make use of q6apm_get_hw_pointer") the position comes from the hw pointer, so a stream that is prepared again, e.g. to recover from an xrun, reports the position of the previous run until the DSP returns its first buffer, while ALSA has reset its own pointer to 0. Reset the hw pointer together with dsp_buf. Fixes: a93dad6f4e6a ("ASoC: q6apm-dai: make use of q6apm_get_hw_pointer") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Vladyslav Tymoshchuk <tvlad744@gmail.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20261014162703.10172-3-tvlad744@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-10-15ASoC: qcom: q6apm-dai: wrap the position of a full ring to 0Vladyslav Tymoshchuk
q6apm_dai_pointer() turns the number of period buffers the DSP has returned in the current lap, 1..periods, into a position and reports one frame less than that. Commit a93dad6f4e6a ("ASoC: q6apm-dai: make use of q6apm_get_hw_pointer") added the "- 1" so that the end of the ring is not reported as a position equal to the buffer size. One frame short has a cost once the application stops feeding the stream. The DSP returns the last queued buffer and the position stops at appl_ptr - 1, so avail stays at buffer_size - 1, below the default stop_threshold. The DSP sends nothing more as its queue is empty, so no period interrupt comes either: ALSA never detects the underrun and the stream stays RUNNING. A poll-driven application that missed its last wakeup waits forever, and drain only ends on its timeout, with -EIO. On capture, the last frame of each period is held back until the next one. Before that commit the position wrapped to 0 at the end of the ring. Do that again. A full lap is the start of the ring, and snd_pcm_update_hw_ptr0() accounts for the wrap: the position cannot move by more than one lap between two updates, as each returned buffer calls snd_pcm_period_elapsed() and the DSP holds at most periods buffers. Seen on a OnePlus Pad 3 (SM8750) with PipeWire in interrupt-driven scheduling: after a stall the PCM sat at hw_ptr 78239, appl_ptr 78240 (avail 3839 of 3840) for two hours. Fixes: a93dad6f4e6a ("ASoC: q6apm-dai: make use of q6apm_get_hw_pointer") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Vladyslav Tymoshchuk <tvlad744@gmail.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20261014162703.10172-2-tvlad744@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-10-15dt-bindings: leds: lacie,netxbig-leds: Convert to DT schemaUdaya Kiran Challa
Convert lacie,netxbig-leds devicetree binding from legacy text format to DT schema. Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20261005184428.251868-1-challauday369@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-10-15dt-bindings: mfd: rockchip,rk805: Convert pinctrl to DT schemaQuchaosheng
pinctrl-rk805.txt describes the pinmux controller that is part of the Rockchip RK805 PMIC. The PMIC itself is already described by rockchip,rk805.yaml, so the pinmux part belongs there as well: the pinctrl node is a child of the PMIC node, not a separate device. Fold the pinmux description into rockchip,rk805.yaml and drop the standalone text binding. While doing so, add the missing child node schema. The rockchip,rk805.yaml schema ends with 'additionalProperties: false' but did not describe the pin configuration child nodes at all, so a valid pinmux node like the one shown in pinctrl-rk805.txt was rejected: pmic@18 (rockchip,rk805): 'rk805-default-pins' does not match any of the regexes: '^pinctrl-[0-9]+$' The pin configuration nodes require 'pins'; without it a node that names no pin is accepted silently, while the text binding it replaces listed 'pins' as required. The RK805 exposes two output-only GPIOs, so 'pins' is an enum of gpio0 and gpio1 and a typo such as "gpio2" is caught. The nodes may be direct children of the PMIC, or sit one level deeper inside a "pinmux" grouping node, which is the layout the example of the text binding used. pinctrl-bindings.txt allows the configuration nodes to be grandchildren of the pin controller, and the driver reaches both layouts: pinconf_generic_dt_node_to_map() parses the referenced node and then walks its children. The example shows both. The example also regains the gpio-controller and #gpio-cells lines that the example of the text binding had. Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://sashiko.dev/#/patchset/20260923034245.396417-1-quchaosheng000406@163.com?part=1 Link: https://sashiko.dev/#/patchset/20260923062746.516666-1-quchaosheng000406@163.com?part=1 Link: https://sashiko.dev/#/patchset/20260923074337.575122-1-quchaosheng000406@163.com?part=1 Assisted-by: LLM Signed-off-by: Quchaosheng <quchaosheng000406@163.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260923083001.606935-1-quchaosheng000406@163.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-10-15leds: pca955x: Drop platform data and allocate LEDs with the deviceRosen Penev
struct pca955x_platform_data has been private to this driver since commit ed1f4b9676a8 ("leds: pca955x: add device tree support"), so nothing can pass it in through dev_get_platdata() and it only serves as an intermediate copy of the per-LED type, default state and fwnode. That copy is a full array of struct pca955x_led, the same runtime structure that struct pca955x already holds, so the data is stored twice. Remove the platform data and parse the child firmware nodes directly into pca955x->leds[]. Make leds[] a flexible array member so it is allocated together with struct pca955x. This removes three allocations and the num_leds sanity check, which could no longer fail. struct pca955x_led moves above struct pca955x, as a flexible array member needs the complete element type. Assisted-by: LLM Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20261005200906.188636-1-rosenp@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-10-15iommu/hyperv: Make hv_iommu_device staticYu Zhang
Make hv_iommu_device static to give it internal linkage. This pointer is only used within hv-iommu-guest.c, but previously has external linkage without a prior declaration. This causes sparse to warn that the symbol was not declared. Fixes: 2690d4156b51 ("iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202610092126.TuSXnTYR-lkp@intel.com/ Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com> Reviewed-by: Jacob Pan <jacob.pan@linux.microsoft.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-10-15iommu/hyperv: Add missing PCI dependency for the guest IOMMU driverYu Zhang
Make HYPERV_PVIOMMU depend on PCI, to fix the possible link failure of pci_request_acs(), if HYPERV_PVIOMMU is enabled yet with PCI disabled. Such configuration shall be prevented. Fixes: 2690d4156b51 ("iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202610110511.Nk1sZ8SG-lkp@intel.com/ Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com> Reviewed-by: Jacob Pan <jacob.pan@linux.microsoft.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>