summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-11objtool/klp: Fix vmlinux .klp.symid link error for .no_trim_symbol symbolsJosh Poimboeuf
Testing klp-build with arm64 produced the following linker error during the original kernel build: `__notrim.1' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.no_trim_symbol' of vmlinux.o symbol_get() puts a static __notrim[] in .no_trim_symbol, which GCC names __notrim.1, __notrim.2, etc. Two or more built-in translation units calling symbol_get() thus produce duplicate names, resulting in corresponding .klp.symid references which trigger the above error. Add .no_trim_symbol to the discarded section list so its symbols don't get symids. Note this issue is not specific to arm64: it just needs two built-in symbol_get() callers. arm64 trips over it easily because it has KVM always compiled in vmlinux, whereas on x86 it's typically a module. Fixes: 029223d30162 ("objtool/klp: Add .klp.symid for sympos disambiguation") Acked-by: Song Liu <song@kernel.org> Acked-by: Joe Lawrence <joe.lawrence@redhat.com> Link: https://patch.msgid.link/5a3cc4cded743167dd0878220201d80f7e48e5d7.1786138493.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
2026-08-12ubi: Fix rollback for explicit UBI device numbersYuho Choi
ubi_init_attach() rolls back module initialization failures by scanning ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes the parameter index matches the UBI device number. That assumption is not true when mtd= specifies an explicit ubi_num. A successfully attached device can be stored at a higher ubi_devices[] slot, and a later failure can miss it during rollback. Scan the full ubi_devices[] array and detach by the actual array index, matching the way UBI devices are stored. Fixes: 83ff59a06663 ("UBI: support ubi_num on mtd.ubi command line") Signed-off-by: Yuho Choi <dbgh9129@gmail.com> Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2026-08-12ubifs: fix out-of-bounds read in signature length checkIbrahim Hashimov
ubifs_sb_verify_signature() bounds the on-disk ubifs_sig_node->len field before handing the signature payload to verify_pkcs7_signature(), but the check has the wrong sign: if (le32_to_cpu(signode->len) > snod->len + sizeof(struct ubifs_sig_node)) The signature bytes start sizeof(struct ubifs_sig_node) (UBIFS_SIG_NODE_SZ, 64 bytes) into the node, so the payload is at most snod->len - sizeof(struct ubifs_sig_node) bytes long. Adding the header size instead of subtracting it accepts a declared length up to 2 * UBIFS_SIG_NODE_SZ larger than the node actually holds -- past the end of c->sbuf, which is vmalloc(c->leb_size). verify_pkcs7_signature() -> pkcs7_parse_message() -> asn1_ber_decoder() is then handed that inflated length and reads beyond the allocation while walking the DER headers. The node length comes straight from the mounted image, so a crafted signed UBIFS image reaches this via ubifs_read_superblock() before the signature is cryptographically checked. snod->len is guaranteed to be >= UBIFS_SIG_NODE_SZ by the node scanner (c->ranges[UBIFS_SIG_NODE].min_len == UBIFS_SIG_NODE_SZ), so the corrected subtraction cannot underflow. Legitimately signed images are unaffected: a correct superblock never declares a signature longer than the node it is embedded in. Fixes: 817aa094842d ("ubifs: support offline signed images") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov <security@auditcode.ai> Assisted-by: AuditCode-AI:2026.07 Reviewed-by: Richard Weinberger <richard@nod.at> Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2026-08-11Merge branch 'bpf-compare-iterator-types-during-state-pruning'Eduard Zingerman
Ning Ding says: ==================== bpf: Compare iterator types during state pruning Iterator stack slots can be marked MEM_RCU or PTR_UNTRUSTED. The STACK_ITER check in stacksafe() does not compare this type, so state pruning can treat these states as equal and prune an unsafe path. Compare the type and add a test where RCU protection has a gap. --- Changes in v2: - Convert the regression test to inline assembly so its verifier-sensitive control-flow layout is stable. - Add Eduard Zingerman's Acked-by tag to patch 1. v1: https://lore.kernel.org/bpf/20260807004320.134069-1-dingning04@gmail.com/ ==================== Link: https://patch.msgid.link/20260811035955.132989-1-dingning04@gmail.com Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-08-11selftests/bpf: Test RCU iterator state pruningNing Ding
Add a path where RCU protection reaches zero and then starts again. The iterator is untrusted after this gap and must be rejected. Signed-off-by: Ning Ding <dingning04@gmail.com> Link: https://patch.msgid.link/20260811035955.132989-3-dingning04@gmail.com Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-08-11bpf: Compare iterator types during state pruningNing Ding
An iterator stack slot can be MEM_RCU or PTR_UNTRUSTED. These states must not be equal, or the verifier can prune an unsafe path. Compare the pointer type for STACK_ITER slots. Fixes: dfab99df147b ("bpf: teach the verifier to enforce css_iter and task_iter in RCU CS") Signed-off-by: Ning Ding <dingning04@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://patch.msgid.link/20260811035955.132989-2-dingning04@gmail.com Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-08-11dt-bindings: arm: omap: Convert L4 interconnect to DT schemaEduard Bostina
Convert the Texas Instruments OMAP L4 interconnect bus bindings to DT schema. During the conversion, several updates were made: - Defined the compatible property as an array to require the TI-specific string first, followed by either 'simple-bus' or 'simple-pm-bus'. - Added a 'select' block to ensure this schema is only applied to TI-specific nodes, preventing duplicate schema warnings against the core simple-pm-bus.yaml. - Added the L4 compatible strings used by the boards but missing from the text binding, and corrected the 'ti,am3-l4-wkup' typo to 'ti,am33xx-l4-wkup'. - Made 'reg' and 'reg-names' optional. Signed-off-by: Eduard Bostina <egbostina@gmail.com> Link: https://patch.msgid.link/20260810134051.380538-1-egbostina@gmail.com [robh: move to bindings/bus/] Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-08-11dt-bindings: power: Convert TI SmartReflex to DT schemaEduard Bostina
Convert the Texas Instruments SmartReflex bindings to DT schema. Signed-off-by: Eduard Bostina <egbostina@gmail.com> Link: https://patch.msgid.link/20260810131641.352391-1-egbostina@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-08-11of: reserved_mem: Introduce devres-managed initialization functionKonrad Dybcio
Introduce devres-based helper for of_reserved_mem_device_init() to help fight dangling references and ever so slightly reduce the number of boilerplate deinitialization calls. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://patch.msgid.link/20260730073214.1146432-1-mukesh.ojha@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-08-11dt-bindings: interrupt-controller: Add StarFive JHB100 plicLey Foon Tan
Add compatible string for StarFive JHB100 plic. Signed-off-by: Ley Foon Tan <leyfoon.tan@starfivetech.com> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Hal Feng <hal.feng@starfivetech.com> Link: https://patch.msgid.link/20260806122553.182449-3-changhuang.liang@starfivetech.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-08-11UBI: fastmap: Pass to_be_tortured when reusing old fastmap PEBsZhihao Cheng
In ubi_update_fastmap(), when no fresh PEB is available to replace an old fastmap PEB, the old PEB is reused by erasing it synchronously via ubi_sync_erase() with the torture flag hardcoded to zero. However, old_fm->to_be_tortured[] may be non-zero: it is set during fastmap scanning when ubi_io_read_data()/ubi_io_read_ec_hdr() reports UBI_IO_BITFLIPS, meaning the PEB showed signs of bit decay and should be tortured to verify it is still reliable. When the old PEB is instead returned to the WL sub-system via ubi_wl_put_fm_peb(), the to_be_tortured flag is honored. The synchronous reuse path is inconsistent: it silently skips the torture test for PEBs that exhibited bit-flips. Fix it by passing &old_fm->to_be_tortured[i] to ubi_sync_erase(). Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2026-08-11UBI: Preserve torture flag when rescheduling failed erasuresZhihao Cheng
In __erase_worker(), when ubi_sync_erase() returns -EINTR, -ENOMEM, -EAGAIN, or -EBUSY, the physical eraseblock is rescheduled for erasure via schedule_erase() with the torture flag hardcoded to 0. This unconditionally drops the torture request. If the error occurred before torture_peb() completed (e.g., -ENOMEM from the ec_hdr allocation in ubi_sync_erase(), errors from self_check_not_bad()/nor_erase_prepare() in ubi_io_sync_erase(), or torture_peb() failing mid-test because its internal do_sync_erase()/ ubi_io_read()/ubi_io_write() returned one of the above error codes), the torture test was never finished. Such a PEB may reach the free pool without being tortured, defeating the purpose of the torture test for detecting marginally-bad eraseblocks. If the error occurred after torture_peb() succeeded (the final do_sync_erase() in ubi_io_sync_erase() or ubi_io_write_ec_hdr() in ubi_sync_erase() failed), the torture has already been done and need not be repeated. Pass the torture flag by pointer to ubi_sync_erase() and ubi_io_sync_erase(), and clear it to zero once torture_peb() has completed successfully. __erase_worker() then forwards the updated wl_wrk->torture to schedule_erase(): torture already done is dropped, torture not completed is preserved across the reschedule. Fixes: 784c145444e7 ("UBI: fix error handling in erase worker") Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2026-08-11alpha: pass -Wa,-mev6 only when using GNU asMatt Turner
That flag exists to stop gas emulating instructions the assembler thinks the target lacks. It is a gas-only option, and LLVM's integrated assembler does not emulate instructions in the first place, so nothing is needed there. Condition it on CONFIG_AS_IS_GNU rather than the compiler, so it is still passed for clang builds using GNU as (LLVM_IAS=0) and omitted only for the integrated assembler. Signed-off-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Magnus Lindholm <linmag7@gmail.com> Link: https://lore.kernel.org/r/20260805185557.3283233-1-mattst88@gmail.com Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
2026-08-11alpha: annotate hardirqs-off on IPL 7 interrupt entryMatt Turner
do_entInt() opens with local_irq_disable(), which with CONFIG_TRACE_IRQFLAGS only calls trace_hardirqs_off() if interrupts were not already off: #define local_irq_disable() \ do { \ bool was_disabled = raw_irqs_disabled();\ raw_local_irq_disable(); \ if (!was_disabled) \ trace_hardirqs_off(); \ } while (0) On alpha raw_irqs_disabled() is (rdps() & 7) == IPL_MAX, i.e. IPL 7. PALcode raises PS.IPL to the level of the interrupt before entInt runs, so for an IPL 7 entry - a processor machine check (vector 0x660) or a system event (vector 0x680), both IPL_MCHECK == IPL_MAX - the gate is already true and the annotation is skipped. lockdep keeps whatever hardirq state the interrupted context had. If that context had interrupts enabled, lockdep believes they are still enabled for the duration of the handler, and every lockdep_assert_irqs_disabled() in the interrupt path fires: WARNING: kernel/context_tracking.c:346 at ct_irq_enter+0xc4/0xd0, CPU#0: swapper/0/0 [...] [<fffffc0001ef74d4>] ct_irq_enter+0xc4/0xd0 [<fffffc000105ebd0>] irq_enter+0x20/0x50 [<fffffc000103707c>] do_entInt+0x1dc/0x2e0 [<fffffc0001031d60>] ret_from_exception+0x0/0x10 irq event stamp: 735356346 hardirqs last enabled at (735356346): trace_hardirqs_on+0x68/0x220 hardirqs last disabled at (735356345): do_idle+0xf0/0x270 The stamps show the problem directly: the most recent event is the enable from the interrupted idle loop, and do_entInt() recorded no disable at all. ct_irq_exit() warns the same way on the way out. Ordinary device interrupts arrive at IPL 3-5 and IPIs and performance counter interrupts at IPL 6, so was_disabled is false for them and the annotation happens normally. Only the two IPL 7 vectors are affected, which is why this needs an environmental event to show up. Take the hardware IPL out of the decision and drive the annotation from lockdep's own state instead. This corrects the annotation only. An IPL 7 event can also interrupt a region that has legitimately disabled interrupts, where irq_enter() and irq_exit() are not the right primitives and NMI semantics are needed; that is a larger change and is left alone here. Tested on an AlphaServer ES47 (Marvel/EV7) by injecting system events through the system management path: fifteen injections, idle and under load, with no splat. The same injection on a freshly booted kernel without this change reproduces both warnings. Signed-off-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Magnus Lindholm <linmag7@gmail.com> Tested-by: Magnus Lindholm <linmag7@gmail.com> Link: https://lore.kernel.org/r/20260810202835.3592833-2-mattst88@gmail.com Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
2026-08-11alpha: run the remote RTC access in a worker, not an IPI callbackMatt Turner
On Marvel the CMOS clock is only reachable from the boot cpu, so remote_read_time() and remote_set_time() bounce the access there with smp_call_function_single(), whose callback runs in hard interrupt context. alpha_rtc_read_time() calls mc146818_get_time() with a 10 ms timeout. That waits out the RTC update cycle in mc146818_avoid_UIP(), which drops rtc_lock and udelay()s 100 us at a time until the update completes or the timeout expires: for (i = 0; UIP_RECHECK_LOOPS_MS(i) < timeout; i++) { spin_lock_irqsave(&rtc_lock, flags); ... if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) { spin_unlock_irqrestore(&rtc_lock, flags); udelay(UIP_RECHECK_DELAY); continue; } So a clock read from a non-boot cpu can spin for up to 10 ms in hard interrupt context on the boot cpu, while the cpu that sent the request spins in smp_call_function_single() waiting for it to finish. mc146818_set_time() does not poll, but it takes rtc_lock too, and rtc_lock is a spinlock_t. Only raw spinlocks may be taken in hard interrupt context, so lockdep reports the write path as soon as a non-boot cpu sets the clock: [ BUG: Invalid wait context ] ----------------------------- swapper/0/0 is trying to lock: fffffc0003690470 (rtc_lock){....}-{3:3}, at: mc146818_set_time+0x74/0x450 other info that might help us debug this: context-{2:2} no locks held by swapper/0/0. stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc1 #1 NONE Trace: [<fffffc000102ebb0>] dump_stack+0x28/0x44 [<fffffc000110efcc>] __lock_acquire+0xb0c/0x1060 [<fffffc000110f5f0>] lock_acquire.part.0+0xd0/0x300 [...] [<fffffc0001b0d834>] mc146818_set_time+0x74/0x450 [<fffffc0001f090cc>] _raw_spin_lock_irqsave+0x7c/0xc0 [<fffffc0001042f90>] do_remote_set+0x90/0xc0 [<fffffc000119c1a4>] __flush_smp_call_function_queue+0x314/0x5c0 [<fffffc000119c474>] generic_smp_call_function_single_interrupt+0x24/0x40 [<fffffc000103d984>] handle_ipi+0xa4/0x230 [<fffffc0001037044>] do_entInt+0x1a4/0x2e0 The rtc class ops are always called from process context, so there is no reason to run the access from an interrupt at all. Use work_on_cpu() to run it in a worker on the boot cpu. Alpha does not support cpu hotplug, so the boot cpu cannot go offline while the work is pending. Tested on an AlphaServer ES47 (Marvel/EV7): hwclock read and write pinned to a non-boot cpu, twenty times, with no splat. Signed-off-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Magnus Lindholm <linmag7@gmail.com> Link: https://lore.kernel.org/r/20260810202835.3592833-1-mattst88@gmail.com Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
2026-08-11Add quad mode support for QPIC SNANDMark Brown
Md Sadre Alam <md.alam@oss.qualcomm.com> says: The Qualcomm QPIC SPI-NAND controller supports both single (x1) and quad (x4) transfer modes, however the current driver operates only in single-bit mode. This series adds support for quad data transfers and includes a vendor-specific fix required for Macronix SPI-NAND devices. Link: https://patch.msgid.link/20260807-quad-v2-0-8ec821e2f22b@oss.qualcomm.com
2026-08-11spi: spi-qpic-snand: Handle Macronix quad read opcode 0x6bMd Sadre Alam
Macronix SPI-NAND devices use opcode 0x6b for quad output cache reads, while most other devices use opcode 0xeb. The QPIC SPI-NAND driver does not currently recognize opcode 0x6b, causing read operations to fail when Macronix devices select this cache read variant. Add the Macronix-specific read opcode to the command mapping logic and treat it the same as the existing quad read operations. This allows Macronix SPI-NAND devices to operate correctly in quad read mode. Signed-off-by: Md Sadre Alam <md.alam@oss.qualcomm.com> Link: https://patch.msgid.link/20260807-quad-v2-3-8ec821e2f22b@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-11spi: spi-qpic-snand: add quad mode supportMd Sadre Alam
Add support for quad (x4) transfer mode in the QPIC SPI NAND driver. The controller supports both single (x1) and quad (x4) SPI transfers, but the driver currently operates only in x1 mode. Track the QUAD enable state from the device configuration register (0xB0) and switch the data transfer width accordingly. When the core enables quad mode, use x4 transfers for read and program operations to improve throughput. Introduce a quad_mode flag in struct qpic_spi_nand to cache the current device state. The flag is updated based on GET_FEATURE responses from the configuration register. Signed-off-by: Md Sadre Alam <md.alam@oss.qualcomm.com> Link: https://patch.msgid.link/20260807-quad-v2-2-8ec821e2f22b@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-11spi: spi-qpic-snand: move command mapping helperMd Sadre Alam
Move qcom_spi_cmd_mapping() above qcom_spi_read_page() so it can be used by read path changes added in a subsequent patch. No functional change. Signed-off-by: Md Sadre Alam <md.alam@oss.qualcomm.com> Link: https://patch.msgid.link/20260807-quad-v2-1-8ec821e2f22b@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-11ASoC: amd: enable audio on HP OmniBook X Flip 14Mark Brown
Ville Saarinen <wiza@saarinenkoti.fi> says: The HP OmniBook X Flip 14-kc0xxx (board 8EA1, Strix Point, ACP 7.2) has no usable audio on mainline at all. Its BIOS reports an ACP configuration flag of FLAG_AMD_LEGACY_ONLY_DMIC, which binds the legacy ACP driver and registers a PDM-only card, so the SoundWire links are never scanned. The two TAS2783 speaker amplifiers on link 0 and the RT712-VB jack codec on link 1 never enumerate, and the machine has no playback path whatsoever. Patch 1 adds a DMI quirk overriding the flag so snd_pci_ps probes. Patch 2 adds the machine entry describing the link topology. With both applied the card comes up and every path on the machine works: internal speakers, headphone jack with detection, headset microphone and the internal DMIC array. Two further patches are needed for the speakers to render stereo rather than mono, and to survive a system resume; those are in the TAS2783 codec driver and are being sent separately to the TI maintainers, since they have no build dependency on this pair. Related reports for the same root cause on other machines: - kernel bugzilla #221226 (ASUS Zenbook S16) - CachyOS linux-cachyos#820 (HP OmniBook X Flip 16, board 8EA2 -- the sibling board, which would need its own entry; I have no access to one and have not added it) Tested on the affected machine only. I do not have any other ACP 7.2 board, so the gating on patch 2 is written to be conservative rather than broad. Testing ======= The hardware testing was done on v7.1.6, where an equivalent version of this pair is what makes audio work on the machine. Against the master commit named below, both patches have been compile-tested only (gcc, W=1, no new warnings, no new external symbol references). Patch 2 has been reworked slightly relative to the tested build: the RT712-VB entry now reuses the existing jack_dmic_endpoints array, which already describes exactly the AIF1 jack + AIF3 DMIC pairing this board needs, instead of adding a second identical copy of it. That was a mechanical substitution, but it has not been through hardware. Tool disclosure, per Documentation/process/generated-content.rst ================================================================ This work was done in extended interactive sessions with Claude (Anthropic, model claude-opus-5) acting as a coding and debugging assistant, and a substantial amount of the analysis and of the patch text originated with it. Both patches carry an Assisted-by tag as described in Documentation/process/coding-assistants.rst. The division of work: - The assistant read the DMI data and ACP configuration flag off the running machine, identified the flag override as the fix, derived the SoundWire topology from the enumerated peripherals, and drafted both patches and both changelogs. - I ran everything that needed root or physical access, rebooted into each build, and did the listening tests. The left/right ordering in patch 2 is set by the order of the two amplifier entries; the first version had the sides reversed and that was caught by ear, not by the assistant. - No single prompt generated these patches. The session was iterative over roughly a day: inspect state, form a hypothesis, build, reboot, measure, discard the hypothesis if the measurement disagreed. Several confident intermediate conclusions were wrong and were only caught by measurement. I have reviewed both patches, I understand what they do, and I take responsibility for them. Link: https://patch.msgid.link/20260809101439.4798-1-wiza@saarinenkoti.fi
2026-08-11ASoC: amd: acp70: add HP OmniBook X Flip 14 SoundWire machineVille Saarinen
Describe the SoundWire topology of the HP OmniBook X Flip 14-kc0xxx (board 8EA1): two TAS2783 smart amplifiers aggregated on link 0 (unique IDs 0xC and 0x9, group_position 0 and 1, name prefixes tas2783-1 and tas2783-2) driving the left and right internal speakers, and an RT712-VB on link 1 providing the headset jack on AIF1 and the internal DMIC array on AIF3. The RT712 amplifier path (AIF2) is left unused because the speakers are driven by the external TAS2783 pair, so the existing jack_dmic_endpoints array describes it exactly. The entry is gated on snd_soc_acpi_amd_sdca_is_device_rt712_vb() so it does not capture a board carrying a different link 1 codec. Developed with AI assistance. The assistant derived the link topology from the enumerated peripherals and drafted the table entry. The order of the two amplifier entries, which is what assigns the physical sides, was corrected after a listening test by the submitter. All hardware measurements quoted above were run by the submitter on the affected machine. The submitter has reviewed the change, understands it and takes responsibility for it. Assisted-by: Claude:claude-opus-5 Signed-off-by: Ville Saarinen <wiza@saarinenkoti.fi> Link: https://patch.msgid.link/20260809101439.4798-3-wiza@saarinenkoti.fi Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-11ASoC: amd: acp-config: force SoundWire probe on HP OmniBook X Flip 14Ville Saarinen
The BIOS on the HP OmniBook X Flip 14-kc0xxx (board 8EA1, Strix Point, ACP 7.2) reports acp-audio-config-flag = FLAG_AMD_LEGACY_ONLY_DMIC. That binds the legacy ACP driver and registers a PDM-only card, so the SoundWire links are never scanned: the two TAS2783 speaker amplifiers on link 0 and the RT712-VB jack codec on link 1 do not enumerate and the machine ends up with no usable playback path at all. Add a DMI entry for the board so the flag is overridden to 0 and snd_pci_ps probes instead. Developed with AI assistance. The assistant read the board's ACP configuration flag out of the running system, identified the flag override as the fix and drafted the DMI entry. All hardware measurements quoted above were run by the submitter on the affected machine. The submitter has reviewed the change, understands it and takes responsibility for it. Assisted-by: Claude:claude-opus-5 Signed-off-by: Ville Saarinen <wiza@saarinenkoti.fi> Link: https://patch.msgid.link/20260809101439.4798-2-wiza@saarinenkoti.fi Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-11ASoC: dt-bindings: qcom,sm8250: Add Maili sound cardMark Brown
Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> says: This series add support for sound card on Qualcomm Maili boards. Link: https://patch.msgid.link/20260811084605.1820056-1-prasad.kumpatla@oss.qualcomm.com
2026-08-11ASoC: qcom: sc8280xp: Add Maili sound card supportPrasad Kumpatla
Add the Maili sound card compatible. Maili can reuse the Hawi sound card data. Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260811084605.1820056-3-prasad.kumpatla@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-11ASoC: dt-bindings: qcom,sm8250: Add Maili sound cardPrasad Kumpatla
Add the Maili sound card compatible to the SM8450-family sound card bindings. Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260811084605.1820056-2-prasad.kumpatla@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-11ASoC: fsl-asoc-card: defer probe when the CPU DAI device is not readyLiangCheng Wang
fsl_asoc_card_probe() hard-fails with -EINVAL when the CPU DAI (SAI) platform device is not found. Like the codec, the CPU DAI may just be probed later than the machine driver; the order is not guaranteed and varies across kernel versions, so a permanent -EINVAL leaves the card unregistered with no analog playback or capture. Defer probe instead, mirroring commit e396dec46c56 ("ASoC: fsl-asoc-card: Defer probe when fail to find codec device"). Tested on i.MX8MP with an ALC5672 on SAI3: the card that failed to register on v6.18 now comes up during boot. Fixes: 708b4351f08c ("ASoC: fsl: Add Freescale Generic ASoC Sound Card with ASRC support") Signed-off-by: LiangCheng Wang <zaq14760@gmail.com> Link: https://patch.msgid.link/20260805-fsl-asoc-defer-cpu-dai-v1-1-43f7f538e384@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-11alpha: don't leak hardware-fabricated FP exception bits to user spaceMatt Turner
On EV6 and later the hardware records exception status bits in the FPCR before delivering a software completion trap, and those bits can be wrong for the instruction that trapped. Converting a double that is exactly representable as a subnormal float sets FPCR_UNF even though the result is exact, and an underflow trap additionally sets FPCR_INE even when the emulated operation turns out to be exact. alpha_fp_emul() only wrote the FPCR when soft-fp raised an exception, so whenever it determined that the instruction was exact the fabricated bits stayed in the FPCR and were reported to user space by fetestexcept(). Pass the exception summary register down from do_entArith() so the handler can tell which exceptions the hardware attributed to the trapping instruction, and always write the FPCR. Clear the exceptions that the trap reported but that soft-fp did not raise. EXC_SUM reports only the underflow or overflow when the hardware also set INE, so treat INE as a candidate in that case, and treat a trap with no reported exception as a denormal operand trap, for which the hardware can fabricate INE and UNF as well. Bits that software has already confirmed in ieee_state belong to this or an earlier instruction and are never cleared. The imprecise path passes no summary. There the trap was taken somewhere in the trap shadow, so EXC_SUM is not attribution for the instruction being re-executed -- and only EV6, which traps precisely and so never takes that path, has fabricated bits to clear. For the same reason the clearing is guarded by implver(), matching swcr_update_status(). On an UP1500 (EV68) this takes the glibc math testsuite from 831 failures to 28, the remainder being unrelated to exception status. This belongs with the preceding fix to ieee_swcr_to_fpcr(), and should not be backported without it -- nor it without this. That fix stops FPCR_DNOD being set unconditionally, so denormal operand traps start firing again. Those traps very often find an exact result, which is precisely the case where the old code left the FPCR unwritten and the fabricated bits visible. Applied alone it would make spurious exception flags more common, not less. One case cannot be resolved here: an inexact instruction without the software completion suffix never traps, so its INE reaches the FPCR without being recorded anywhere else. Such a bit is indistinguishable from an INE the hardware fabricated for a trapping instruction, and is lost if an underflow or overflow trap with an exact result follows it. The FPCR is the only record of those instructions and it carries no attribution. The bug predates the git history, so there is no commit to reference in a Fixes tag. Cc: stable@vger.kernel.org # 5.15+ Signed-off-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Magnus Lindholm <linmag7@gmail.com> Tested-by: Magnus Lindholm <linmag7@gmail.com> Link: https://lore.kernel.org/r/20260803-alpha-fp-exceptions-v1-2-c99d75608e60@gmail.com Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
2026-08-11alpha: fix ieee_swcr_to_fpcr setting FPCR_DNOD unconditionallyMatt Turner
ieee_swcr_to_fpcr() converts the software IEEE trap-enable and status bits kept in thread_info.ieee_state into the hardware FPCR format. It contained: fp |= (~sw & IEEE_TRAP_ENABLE_DNO) << 41; FPCR_DNOD (bit 47) disables denormal operand traps: with it set the hardware handles a denormal operand itself, treating it as zero, instead of trapping for software completion. The intent was to set DNOD when the user has not asked for SIGFPE on denormal operands, but IEEE_TRAP_ENABLE_DNO is clear by default, so ieee_swcr_to_fpcr(0) always set DNOD. Instructions built with the software completion suffix therefore never trapped on a denormal operand. The hardware silently substituted zero and produced wrong results, affecting every program compiled with -mieee and default FPU settings, glibc included. Set FPCR_DNOD only when IEEE_MAP_DMZ is requested, which is exactly the case where flushing denormal inputs to zero is what the user asked for. DNOD then encodes MAP_DMZ, which ieee_fpcr_to_swcr() already recovers from FPCR_DNZ, so drop its attempt to recover IEEE_TRAP_ENABLE_DNO from DNOD; the DNO trap enable lives solely in ieee_state. Both functions are in a uapi header, so the encoding change is visible to userspace, but nothing outside the kernel is known to depend on DNOD carrying the DNO trap enable, and the kernel is the only writer of the FPCR. This must not be backported on its own. Re-enabling denormal operand traps exposes a second bug, fixed in the following patch: those traps usually find an exact result, and for an exact result the emulator did not write the FPCR back, leaving hardware-fabricated exception bits visible to user space. Taken alone this change would make spurious exception flags more common. The bug predates the git history, so there is no commit to reference in a Fixes tag. Cc: stable@vger.kernel.org # 5.15+ Signed-off-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Magnus Lindholm <linmag7@gmail.com> Tested-by: Magnus Lindholm <linmag7@gmail.com> Link: https://lore.kernel.org/r/20260803-alpha-fp-exceptions-v1-1-c99d75608e60@gmail.com Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
2026-08-11ASoC: pxa: Use devm_clk_get_optional() for extclk clockbui duc phuc
The Device Tree binding defines the extclk clock as an optional property, but the driver currently uses devm_clk_get() and manually handles the absence of the clock. Use devm_clk_get_optional() to match the binding and simplify the optional clock handling. This also propagates errors other than the absence of the optional clock, including -EPROBE_DEFER. This changes the existing behavior for errors other than -EPROBE_DEFER. RFC to discuss whether these errors should cause probe to fail rather than being treated as an unavailable optional clock. Fixes: 90eb6b59d311 ("ASoC: pxa-ssp: add support for an external clock in devicetree") Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260811100949.61142-1-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-11ubifs: ubifs.h: clean up kernel-doc commentsRandy Dunlap
- use the struct keyword when describing a struct in kernel-doc format. - add or correct missing struct members @leaf, @eof, and @superblock_need_write. - add Returns: clauses for 4 function descriptions. to prevent kernel-doc warnings: Warning: fs/ubifs/ubifs.h:755 struct member 'leaf' not described in 'ubifs_zbranch' Warning: fs/ubifs/ubifs.h:814 struct member 'eof' not described in 'bu_info' Warning: fs/ubifs/ubifs.h:814 Excess struct member 'oef' description in 'bu_info' Warning: fs/ubifs/ubifs.h:992 cannot understand function prototype: 'struct ubifs_stats_info' Warning: fs/ubifs/ubifs.h:1513 struct member 'superblock_need_write' not described in 'ubifs_info' Warning: fs/ubifs/ubifs.h:1597 No description found for return value of 'ubifs_check_hash' Warning: fs/ubifs/ubifs.h:1612 No description found for return value of 'ubifs_check_hmac' Warning: fs/ubifs/ubifs.h:1653 No description found for return value of 'ubifs_branch_hash' Warning: fs/ubifs/ubifs.h:1703 No description found for return value of 'ubifs_auth_node_sz' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2026-08-11ubifs: key.h: use correct function parameter nameRandy Dunlap
Use @hash as the function parameter name to prevent kernel-doc warnings: Warning: fs/ubifs/key.h:42 function parameter 'hash' not described in 'key_mask_hash' Warning: fs/ubifs/key.h:42 Excess function parameter 'val' description in 'key_mask_hash' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2026-08-11ubifs: debug.h: fix kernel-doc struct prototypesRandy Dunlap
Use the "struct" keyword to describe structs in kernel-doc format. This avoids kernel-doc warnings: Warning: fs/ubifs/debug.h:75 cannot understand function prototype: 'struct ubifs_debug_info' Warning: fs/ubifs/debug.h:130 cannot understand function prototype: 'struct ubifs_global_debug_info' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Richard Weinberger <richard@nod.at>
2026-08-11idpf: add missing cpu_to_le32 in idpf_tx_splitq_build_flow_descWillem de Bruijn
idpf_tx_splitq_build_flow_desc performs a 32-bit store to &cmd_dtype to set the 8-bit cmd_dtype and zero the adjacent 3-byte timestamp field in a single operation. Descriptors are in little endian. Add missing cpu_to_le32 and cast to __le32 to ensure the fields are written correctly also on big endian platforms. Fixes: 1a49cf814fe1 ("idpf: add Tx timestamp flows") Signed-off-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Jason Xing <kerneljasonxing@gmail.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-11ice: acquire NVM lock around each flash readRobert Malz
FW caps the NVM read lock at a maximum of 3000ms regardless of the timeout requested via ice_acquire_nvm(). ice_read_flat_nvm() splits a read into multiple ice_aq_read_nvm() commands, one per 4KB sector, all issued under a single lock taken by the caller. Reading a large region can exceed 3000ms, so FW reclaims the lock mid-read and the remaining commands might fail. Move the lock acquire/release into ice_read_flat_nvm() so it brackets each individual ice_aq_read_nvm() command, ensuring the lock is never held across more than one FW read. ice_release_nvm() issues its own AQ command and overwrites hw->adminq.sq_last_status, which some callers inspect after a failed read. Add an optional read_aq_err output parameter to ice_read_flat_nvm() to capture the failing read's AQ error before the release; callers that need it (ice_discover_flash_size() and the ethtool/devlink log paths) use it instead of sq_last_status, others pass NULL. Callers that previously took the lock around ice_read_flat_nvm(), ice_read_sr_word() or ice_read_flash_module() now call them without it. The now-redundant per-block locking in ice_devlink_nvm_snapshot() is dropped. ice_read_sr_word() is now a thin wrapper, so ice_read_sr_word_aq() is folded into it. Fixes: e94509906d6b ("ice: create function to read a section of the NVM and Shadow RAM") Signed-off-by: Robert Malz <robert.malz@canonical.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-11ice: clear the default forwarding VSI rule when releasing a VSIPetr Oros
When a VSI is configured as the switch's default forwarding VSI (ICE_SW_LKUP_DFLT) and is then torn down, the rule is left behind in the switch. ice_vsi_release() no longer removes it, and the SR-IOV VF free path (ice_free_vfs() -> ice_free_vf_res() -> ice_vf_vsi_release() -> ice_vsi_release()) does not disable promiscuous mode either, which only happens on VF reset in ice_vf_clear_all_promisc_modes(). A trusted VF that enters unicast promiscuous mode becomes the default forwarding VSI (this is the default mode, when the PF does not have VF true-promiscuous mode enabled). If the VFs are then destroyed without the VF first leaving promiscuous mode, the ICE_SW_LKUP_DFLT rule for the now-freed VSI is leaked. When VFs are recreated, a VSI reuses the freed hw_vsi_id. If it is assigned a different VSI handle than the leaked rule holds, ice_set_dflt_vsi() does not recognize it as already-default, and ice_add_update_vsi_list() folds the dangling (freed) handle into a VSI list, which the firmware rejects. The VSI handle assigned on re-creation varies, so the failure is intermittent rather than every cycle. Reproduce by repeatedly running the cycle below on the two ports of the same card, where $VF0 and $VF1 are the netdevs of vf 15 once they appear. The VF must be brought up so iavf actually pushes the unicast promiscuous request, and the rule must settle before the VFs are torn down again: echo 16 > /sys/class/net/$PF0/device/sriov_numvfs echo 16 > /sys/class/net/$PF1/device/sriov_numvfs ip link set $PF0 vf 15 trust on ip link set $PF1 vf 15 trust on ip link set $VF0 up ip link set $VF1 up ip link set $VF0 promisc on ip link set $VF1 promisc on sleep 1 echo 0 > /sys/class/net/$PF0/device/sriov_numvfs echo 0 > /sys/class/net/$PF1/device/sriov_numvfs Within a few cycles the ice PF and iavf VF log: Failed to set VSI 25 as the default forwarding VSI, error -22 Turning on/off promiscuous mode for VF 63 failed, error: -22 PF returned error -53 (IAVF_ERR_ADMIN_QUEUE_ERROR) to our request 14 This cleanup used to live in ice_vsi_release() but was dropped by the referenced refactor. Restore it. Clear the default forwarding VSI rule in ice_vsi_release() when this VSI owns it, which covers every teardown path. Fixes: 6624e780a577 ("ice: split ice_vsi_setup into smaller functions") Signed-off-by: Petr Oros <poros@redhat.com> Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-11ice: fall back to SBQ when LL PHY timer interface times outPrzemyslaw Korba
The low-latency (LL) PHY timer interface relies on a tight, atomic poll of the PF_SB_ATQBAL register with a 2ms timeout. After an NVM update / EMPR, FW may need significantly longer than 2ms to start responding to ATQBAL commands. The first PHY adjust or incval write issued by ice_ptp_rebuild_owner() fails with -ETIMEDOUT. Fix this by falling back to the existing SBQ-based PHY register write path when LL times out. This makes sure PTP is initialized when FW takes longer than expected to come back online. Steps to reproduce: ./nvmupdate64e -if devlink -f Update E810 card with nvmupdate64e, and observe dmesg errors: Failed to write PHC increment value, status -110 PTP reset failed, error: -110 (-ETIMEDOUT) Fixes: ef9a64c07294 ("ice: implement low latency PHY timer updates") Signed-off-by: Przemyslaw Korba <przemyslaw.korba@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-11RDMA/cma: Fix WARNING in res_to_rtZhu Yanjun
syzbot reported a WARN_ON(!res->dev) in res_to_rt() triggered via addr_handler() during asynchronous address resolution: " WARNING: drivers/infiniband/core/restrack.c:138 at res_to_rt+0x1c4/0x230 CPU#1: kworker/u8:4/59 Modules linked in: CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine, BIOS Google 07/24/2026 Workqueue: ib_addr process_one_req RIP: 0010:res_to_rt+0x1c4/0x230 drivers/infiniband/core/restrack.c:138 RSP: 0018:ffffc9000201f850 EFLAGS: 00010293 RAX: ffffffff88d00ce5 RBX: ffff88807f0fd4f8 RCX: ffff88801e6e0000 RDX: 0000000000000000 RSI: ffffffff8fd996f0 RDI: 0000000000000003 RBP: 0000000000000000 R08: ffff88801e6e0000 R09: 000000000000000a R10: 0000000000000009 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff1100fe1fa9f R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff888125012000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001d559c3d2000 CR3: 0000000077c4c000 CR4: 00000000003526f0 Call Trace: <TASK> rdma_restrack_add+0x5a/0x8a0 drivers/infiniband/core/restrack.c:236 addr_handler+0x41a/0x5a0 drivers/infiniband/core/cma.c:3534 process_one_req+0x2eb/0x540 drivers/infiniband/core/addr.c:624 process_one_work kernel/workqueue.c:3375 [inline] process_scheduled_works+0xc4e/0x1630 kernel/workqueue.c:3458 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3539 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> " In addr_handler(), cma_acquire_dev_by_src_ip() is called to populate id_priv->cma_dev and bind the associated ib_device to id_priv->id.device. If cma_acquire_dev_by_src_ip() returns an error (non-zero status), the ID remains unassociated with any RDMA device. Previously, rdma_restrack_add(&id_priv->res) was invoked unconditionally even when cma_acquire_dev_by_src_ip() failed, passing a resource with a NULL dev pointer and triggering the WARN_ON assertion in res_to_rt(). Fix this by only adding the resource to restrack when acquiring the device succeeds. Reported-by: syzbot+72eddfbadda3e3928e72@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=72eddfbadda3e3928e72 Tested-by: syzbot+72eddfbadda3e3928e72@syzkaller.appspotmail.com Fixes: cb5cd0ea4eb3 ("RDMA/core: Add CM to restrack after successful attachment to a device") Link: https://patch.msgid.link/r/20260810220123.191696-1-yanjun.zhu@linux.dev Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-08-11RDMA/cxgb4: Free debugfs on registration failureFan Wu
c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via setup_debugfs()), but it is removed only in c4iw_remove(), not in c4iw_dealloc(). When RDMA device registration fails, the registration worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing c4iw_remove(), so the debugfs dentries leak and outlive the freed c4iw_dev. Move debugfs_remove_recursive() into c4iw_dealloc() so every path that frees ctx->dev also removes its debugfs tree. Fixes: 49ea0c036ede ("RDMA/iw_cxgb4: cleanup device debugfs entries on ULD remove") Link: https://patch.msgid.link/r/20260806130128.465460-2-fanwu01@zju.edu.cn Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-08-11RDMA/cxgb4: Cancel reg_work before freeing device on removeFan Wu
c4iw_uld_state_change() queues reg_work to register the RDMA device. c4iw_remove() can free ctx->dev while this work is pending or running, leaving c4iw_register_device() accessing the freed device. Cancel reg_work before removing the device. The registration work can tear down ctx->dev when registration fails, so do not unregister or deallocate it again in that case. This issue was found by an in-house static analysis tool. Fixes: 1c8f1da5d851 ("iw_cxgb4: Fix possible circular dependency locking warning") Link: https://patch.msgid.link/r/20260806130128.465460-1-fanwu01@zju.edu.cn Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-08-11ring-buffer: drop unneeded semicolonJulia Lawall
When a function-like macro expands to an expression, that expression doesn't need a semicolon after it. All uses have been verified to have their own semicolons. This was found using the following Coccinelle semantic patch: @r@ identifier i : script:ocaml() { String.lowercase_ascii i = i }; expression e; @@ *#define i(...) e; Link: https://patch.msgid.link/20260801191002.1383835-6-Julia.Lawall@inria.fr Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-08-12dmaengine: dw-edma: Mark emulated IRQ as level-triggeredKoichiro Den
The interrupt-emulation virtual IRQ uses handle_level_irq(), but the IRQ descriptor has not been marked with IRQ_LEVEL. The interrupt emulation is somewhat unusual: the eDMA interrupt handlers dispatch the virtual IRQ for every edma_int[] interrupt because software cannot reliably tell an interrupt-emulation event from one caused solely by DONE/ABORT status. If an interrupt arrives before the doorbell handler is registered for the virtual IRQ, the IRQ core marks it pending. When the IRQ is later started, check_irq_resend() treats it as non-level and replays the pending interrupt, causing the newly registered handler to run for a stale event. Mark the virtual IRQ with IRQ_LEVEL so the stale pending state is cleared without being replayed. This was observed in pci_endpoint_test as two doorbell handler calls when the DMA-variant test ran before DOORBELL_TEST. Fixes: d9d5e1bdd180 ("dmaengine: dw-edma: Add virtual IRQ for interrupt-emulation doorbells") Cc: stable@vger.kernel.org Reported-by: Niklas Cassel <cassel@kernel.org> Closes: https://lore.kernel.org/r/ampndLtU32ODmncX@ryzen Tested-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Koichiro Den <den@valinux.co.jp> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260730160701.3550710-1-den@valinux.co.jp Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11dmaengine: idxd: assign all engines to group 0 in IAA defaultsGiovanni Cabiddu
The IAA device defaults only assigned engine 0 to group 0, leaving engines 1 through max_engines-1 unassigned (group_id = -1). This means that by default only a single engine processed descriptors, limiting throughput to one engine's capacity. Assign all available engines to group 0 so that the full hardware parallelism is used out of the box without requiring manual accel-config setup. Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260805-iaa-crypto-fixes-zswap-v2-1-55c02694f499@intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11dmaengine: qcom_hidma: remove conditional return with no effectSang-Heon Jeon
Both branches of the check return the same value, so the check has no effect. Remove it and return the value directly. This is the result of running the Coccinelle script from scripts/coccinelle/misc/cond_return_no_effect.cocci. Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Link: https://patch.msgid.link/20260723184538.3888637-20-ekffu200098@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11dmaengine: qcom-bam-dma: fix autosuspend cleanup during removalGuangshuo Li
bam_dma_probe() calls pm_runtime_use_autosuspend(), but bam_dma_remove() does not call the matching pm_runtime_dont_use_autosuspend() when removing the device. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call before forcing the device into runtime suspend during removal. This issue was found by manual code inspection. Fixes: 7d2545599f5b ("dmaengine: qcom-bam-dma: Add pm_runtime support") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260808110642.2770355-1-lgs201920130244@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11orangefs: skip leading spaces before parsing client debug masksZhiling Zou
orangefs_prepare_cdm_array() sizes each client debug keyword buffer with strcspn(cds_head, " "), but then parses the keyword with %s. The %s conversion skips leading whitespace, while strcspn() does not. If a client debug entry starts with a space, the allocation can be sized for an empty keyword while sscanf() copies the following non-empty token. This can write past the end of the allocated keyword buffer. Skip leading spaces before computing the keyword length so the allocation matches the string parsed by sscanf(). Fixes: f7be4ee07fb7 ("Orangefs: kernel client part 4") Cc: stable@vger.kernel.org Reported-by: Vega <vega@nebusec.ai> Assisted-by: Codex:gpt-5.4 Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai> Signed-off-by: Ren Wei <enjou1224z@gmail.com> Signed-off-by: Mike Marshall <hubcap@omnibond.com>
2026-08-11orangefs: Remove commented out code in find_cached_xattrThorsten Blum
The code has been commented out since 2017 - remove it. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Mike Marshall <hubcap@omnibond.com>
2026-08-11orangefs: use folio_pos() and folio_size() in orangefs_page_mkwrite()Tal Zussman
orangefs_page_mkwrite() records the faulted range with page_offset(vmf->page) and PAGE_SIZE, although the write range it sets is attached to the folio and the rest of the function already operates on folios. Use folio_pos() and folio_size() instead. This gets rid of two calls to page_offset(), removing two calls to compound_head(). No functional change. orangefs folios are always order-0, so the values are identical. However, if orangefs ever enables large folios, this change is necessary for correctness with the current write range tracking scheme. Tracking only a single page of a larger folio would leave the rest of the folio's dirty data outside the range that gets written back, leading to data loss. Signed-off-by: Tal Zussman <tz2294@columbia.edu> Signed-off-by: Mike Marshall <hubcap@omnibond.com>
2026-08-11orangefs: fix double-free of trailer_buf on readdir copy failureYifei Gao
On a readdir downcall, orangefs_devreq_write_iter() frees op->downcall.trailer_buf with vfree() when copy_from_iter_full() fails, but does not clear the pointer before goto Efault. The waiter in do_readdir() is then woken with a negative status and frees the same pointer again on its r < 0 path, causing a deterministic double-free. A client holding /dev/pvfs2-req triggers it by sending a readdir downcall whose declared trailer_size exceeds the bytes it supplies. Clear the pointer after freeing so the readdir-side vfree() becomes a no-op. Fixes: 382f4581e67f ("orangefs: rewrite readdir to fix several bugs") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yifei Gao <gyf161023@gmail.com> Signed-off-by: Mike Marshall <hubcap@omnibond.com>
2026-08-11dmaengine: fsl-edma: tracing: no ptr dereference during log outputMartin Kaiser
The fsl edma events store a pointer to a struct fsl_edma_engine in the ringbuffer and dereference it when a log entry is printed. At this time, the pointer may no longer be valid. Event injection can be used to trigger a crash: $ cd /sys/kernel/tracing $ echo 'value = 0' > events/fsl_edma/edma_writeb/inject $ cat trace The log output needs only edma->membase. Add a membase field at the end of the event and use the new field for log output. Keep the existing fields for backward compatibility. Fixes: 11102d0c343b ("dmaengine: fsl-edma: add trace event support") Cc: stable@vger.kernel.org Reviewed-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Martin Kaiser <martin@kaiser.cx> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260718130024.341243-1-martin@kaiser.cx Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11KVM: arm64: vgic: Fix detection of MI on no pending LRKajetan Puchalski
As per the ARM GICv3 spec, the maintenance interrupt identified by ICH_MISR_EL2.NP is asserted when it is enabled and no List register is in pending state. This is further described in the document as "no List registers with the State field set to 0b01 (pending)". By checking only the pending bit of the LR (bit 62), KVM currently asserts the MI when there are no LRs in "pending" or "pending and active" states. Fix the detection logic to consider only the "pending" state. Cc: stable@vger.kernel.org Fixes: 96c2f03311de ("KVM: arm64: nv: Plumb handling of GICv3 EL2 accesses") Signed-off-by: Kajetan Puchalski <kajetan.puchalski@arm.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260810102923.2426475-2-kajetan.puchalski@arm.com Signed-off-by: Oliver Upton <oupton@kernel.org>