summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
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>
2026-08-11KVM: arm64: Drop %pB on nVHE panic when stage-2 is activeVincent Donnefort
With pKVM, the host stage-2 is lazily mapped. kallsyms, accessed via the modifier %pB is therefore potentially unmapped. If the hyp panic occurred while the host stage-2 lock was held, handling this fault deadlocks. Skip %pB formatting unless the host stage-2 is disabled. Fixes: 6ccf9cb557bd ("KVM: arm64: Symbolize the nVHE HYP addresses") Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev> Tested-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260803093906.3531699-1-vdonnefort@google.com Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-08-11KVM: arm64: vgic: Reset in_kernel on private IRQ allocation failureFuad Tabba
kvm_vgic_create() sets vgic.in_kernel before allocating the per-vCPU private IRQs, but the allocation-failure path resets only vgic_model and leaves in_kernel set. As irqchip_in_kernel() is !!in_kernel, the VM is left with an in-kernel irqchip but no model, and the -EEXIST guard at the top of kvm_vgic_create() rejects every retry, so userspace cannot recover from a transient -ENOMEM. Reset in_kernel alongside vgic_model on the failure path. Fixes: 9435c1e1431003 ("KVM: arm64: gic: Set vgic_model before initing private IRQs") Cc: stable@vger.kernel.org Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260802150845.3485757-1-fuad.tabba@linux.dev Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-08-11KVM: arm64: GICv2: Don't WARN on out-of-range GICV_DIR INTIDKarl Mehltretter
vgic_v2_deactivate() passes the INTID a guest wrote to GICV_DIR straight to vgic_get_vcpu_irq(), and treats a failed lookup as a "can't happen" condition with WARN_ON_ONCE(). The guest can make it happen at will, though: for any INTID outside of the implemented SGI, PPI and SPI ranges the lookup returns NULL, since GICv2 has no LPIs. A guest running with EOImode==1 writing such an INTID to GICV_DIR triggers the WARN, and panics hosts running with panic_on_warn. Drop the WARN and ignore failed lookups. Fixes: 255de897e7fb ("KVM: arm64: GICv2: Handle deactivation via GICV_DIR traps") Cc: stable@vger.kernel.org Suggested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Link: https://patch.msgid.link/20260726174803.5880-1-kmehltretter@gmail.com Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-08-11KVM: arm64: Preserve GPRs for AArch32 CP64 reads generating an UNDEFKarl Mehltretter
kvm_handle_cp_64() only seeds params.regval for writes. If a CP64 read is decoded but UNDEFs, emulate_cp() still returns handled and the caller writes params.regval back to Rt/Rt2. This can happen for PMU counter read accesses generating an UNDEF. KVM injects the exception into the guest, so the MRRC GPRs must remain unchanged. Instead, the uninitialised regval is copied into the guest GPRs. With stack auto-initialisation this is a deterministic zero or pattern value. With CONFIG_INIT_STACK_NONE it may be stale host stack data. Match kvm_handle_cp_32() and kvm_handle_sys_reg() by seeding regval from the GPRs before emulation. Fixes: 62a89c44954f0 ("arm64: KVM: 32bit handling of coprocessor traps") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260802182222.2239-1-kmehltretter@gmail.com Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-08-11RDMA/ucma: Lock the handler in ucma_set_ib_path()Norbert Szetei
ucma_set_ib_path() calls ucma_event_handler() straight from the write() path, without the handler lock that keeps ctx->file stable while a uevent is queued. The handler re-reads ctx->file for every dereference: mutex_lock(&ctx->file->mut); /* file A */ list_add_tail(&uevent->list, &ctx->file->event_list); /* file B */ mutex_unlock(&ctx->file->mut); /* file B */ wake_up_interruptible(&ctx->file->poll_wait); /* file B */ A concurrent ucma_migrate_id() reassigns ctx->file while the SET_OPTION caller sleeps in mutex_lock(), so the list_add_tail() lands on file B's event_list while only file A's mutex is held, racing every other user of that list: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0 Read of size 8 at addr ffff888153c6a418 by task poc_corr/486 Call Trace: __list_add_valid_or_report+0x1aa/0x1c0 ucma_event_handler+0x1be/0xc00 ucma_set_ib_path+0x45e/0x710 ucma_set_option+0x32e/0x590 ucma_write+0x1f9/0x330 Allocated by task 505: ucma_write_cm_event+0x1a1/0x660 Freed by task 505: kfree+0x1da/0x4c0 ucma_get_event+0x5d5/0x7e0 The freed object is a ucma_event that another thread dequeued from file B's list under file B's mutex. File A's mut is left held on top of that, wedging its next writer in uninterruptible sleep. This path needs a bound and address-resolved cm_id, so it requires an RDMA device to be present. Take the handler lock around the call. Fixes: 09e328e47a69 ("RDMA/ucma: Fix the locking of ctx->file") Link: https://patch.msgid.link/r/2823D190-92D5-4714-8769-4FB643C64FF3@doyensec.com Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Norbert Szetei <norbert@doyensec.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-08-11RDMA/ucma: Lock the handler in ucma_write_cm_event()Norbert Szetei
ctx->file may only be changed under the handler lock and the xa_lock, which is what stops uevents being queued for a ctx while ucma_migrate_id() moves it to another file. The CM core takes that lock before invoking ucma_event_handler(), but the write() paths that queue uevents themselves do not. ucma_write_cm_event() re-reads ctx->file for each of its four dereferences, so ucma_migrate_id() can swap it mid-sequence: mutex_lock(&ctx->file->mut); /* file A */ list_add_tail(&uevent->list, &ctx->file->event_list); /* file B */ mutex_unlock(&ctx->file->mut); /* file B */ wake_up_interruptible(&ctx->file->poll_wait); /* file B */ The window is the mutex_lock() itself: the writer sleeps in it while the migration reassigns ctx->file. The list_add_tail() then runs on file B's event_list holding only file A's mutex: list_add corruption. prev->next should be next (ffff888101320f30), but was ffff88814a08c418. (prev=ffff88814a075c18). kernel BUG at lib/list_debug.c:32! Call Trace: ucma_write_cm_event+0x36e/0x5e0 and file A's mut is left held forever, wedging its next writer in D state. The uevent is also stranded on a list ucma_cleanup_ctx_events() will not walk, so it outlives its context. /dev/infiniband/rdma_cm is 0666 and no RDMA device is involved, so an unprivileged user reaches all of this. Take the handler lock, as ucma_cleanup_mc_events() does; ctx->cm_id is pinned by the ucma_get_ctx() reference. Fixes: a3c9d0fcd371 ("RDMA/ucma: Support write an event into a CM") Link: https://patch.msgid.link/r/60544A67-EFD6-4D5D-974C-D983445F1070@doyensec.com Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Norbert Szetei <norbert@doyensec.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-08-11nvme: ratelimit the completion-path messages driven by device dataChao Shi
nvme_find_rq() and nvme_handle_cqe() print an unratelimited message for every completion queue entry whose command id does not resolve to an in-flight request. Both are reached from the completion interrupt path (nvme_irq() -> nvme_poll_cq() -> nvme_handle_cqe()) and the decision to print is made entirely from device-supplied data, so a controller that posts a stream of bogus command ids drives unbounded printk from hard interrupt context. This is not hypothetical. A single boot under an emulated controller that posts invalid completions produced 846 "could not locate request for tag 0x0", 846 "invalid id 0 completed on queue 2" and 123 "genctr mismatch" lines. Once the tag set has been torn down every subsequent completion resolves to nothing, so the print rate is bounded only by how fast the device can post entries. Ratelimit the three messages. The information they carry is diagnostic and repeats, so the suppression count printed by the ratelimit helpers is enough to tell that the condition persists. This matches how the other device-driven error prints in the driver are already handled, for example the status messages in nvme_log_error() and nvme_log_err_passthru(). nvme_find_rq() lives in nvme.h and is shared by pci, tcp, rdma, apple and target-loop, so all transports are covered. Found by FuzzNvme. Signed-off-by: Chao Shi <coshi036@gmail.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-08-11MAINTAINERS: Add Manivannan Sadhasivam as the Reviewer for Generic PHY FrameworkManivannan Sadhasivam
I'm volunteering to review the PHY patches. Hence, add myself as the Reviewer. Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260811143417.336664-1-mani@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip-samsung-dcphy: fix out-of-range max_registerJason Yang
The PHY register block is 64KB, so with a register stride of 4 the last accessible register sits at offset 0xfffc. max_register names 0x10000, one register past the end of the mapping: dumping the registers through the regmap debugfs interface reads beyond the ioremapped region and oopses on the unmapped page. The oops fires with the regmap lock held, so later PHY operations deadlock. Fixes: b2a1a2ae7818 ("phy: rockchip: Add Samsung MIPI D-/C-PHY driver") Cc: stable@vger.kernel.org Signed-off-by: Jason Yang <jason98166@gmail.com> Assisted-by: Claude:claude-opus-5 Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patch.msgid.link/20260811-dcphy-maxreg-v1-v1-1-aa63f6a63a64@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: qcom: qmp-pcie: Add QMP PCIe Multi-PHY driverQiang Yu
Some QMP PCIe PHY hardware blocks support multiple link topologies (e.g. x8 or x4+x4) selected via a TCSR register. The existing single-instance QMP PCIe PHY driver has no way to model this: it assumes a single cfg per DT node and instantiates exactly one PHY. Add a dedicated driver for this class of PHY. Match data carries a per-mode cfg table; qmp_pcie_multiphy_probe() reads the current link mode from the TCSR register pointed to by "qcom,link-mode", looks up the corresponding cfg array, and instantiates one qmp_pcie per sub-PHY required by that link mode, registering the clock and #phy-cells = <1> phy providers so consumers can address individual sub-PHYs by index. The driver inherits the phy setting and link-mode programmed by firmware, so only the no_csr reset is used and no phy setting tables are provided. Add the first match data and compatible, qcom,glymur-qmp-gen5x8-pcie-phy, for the Glymur Gen5 PCIe PHY that can bifurcate into two x4 links or operate as a single x8 link. Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Link: https://patch.msgid.link/20260807-glymur_linkmode_0807-v9-2-dd1c7e236e29@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11dt-bindings: phy: qcom: Add Glymur QMP PCIe multiple link-mode PHYQiang Yu
Add qcom,glymur-qmp-gen5x8-pcie-phy.yaml as a standalone binding for the Glymur Gen5 PCIe PHY hardware block. This block supports two link modes, selected at runtime via a TCSR syscon register: 1. x8 - a single 8-lane PHY instance is exposed 2. x4+x4 - two independent 4-lane PHY instances are exposed Keep this as a separate schema from qcom,sc8280xp-qmp-pcie-phy.yaml rather than folding it into the shared compatible list there, since the two PHY instances active in x8 mode require twice as many clocks, resets, and power-domains as any other entry in that file, and adding Glymur-specific properties like qcom,link-mode and reg-names there would only apply to this one compatible. Document the required clocks, resets, and power-domains for both PHY instances, and use #phy-cells = <1>, where the cell value is the PHY index within the active link mode. Acked-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Link: https://patch.msgid.link/20260807-glymur_linkmode_0807-v9-1-dd1c7e236e29@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Consistently use bitfield macrosCristian Ciocaltea
Make the code more robust and improve readability by using the available bitfield macros (e.g. FIELD_PREP, FIELD_GET) whenever possible, instead of open coding the related bit operations. Tested-by: Thomas Niederprüm <dubito@online.de> Tested-by: Simon Wright <simon@symple.nz> Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-10-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Simplify GRF access with FIELD_PREP_WM16()Cristian Ciocaltea
The 16 most significant bits of the general-purpose register (GRF) are used as a write-enable mask for the remaining 16 bits. Make use of the recently introduced FIELD_PREP_WM16() macro to avoid open-coding the bit shift operations and improve code readability. Tested-by: Thomas Niederprüm <dubito@online.de> Tested-by: Simon Wright <simon@symple.nz> Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-9-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Drop restrict_rate_change handlingCristian Ciocaltea
Since commit 6efbd0f46dd8 ("phy: rockchip: samsung-hdptx: Restrict altering TMDS char rate via CCF"), adjusting the rate via the Common Clock Framework API has been disallowed. To avoid breaking existing users until switching to the PHY config API, it introduced a temporary exception to the rule, controlled via the 'restrict_rate_change' flag. As the API transition completed, remove the now deprecated exception logic. Tested-by: Thomas Niederprüm <dubito@online.de> Tested-by: Simon Wright <simon@symple.nz> Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-8-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Consolidate consumer_put on error pathCristian Ciocaltea
rk_hdptx_phy_consumer_put() is invoked in both branches of the mode check conditional in rk_hdptx_phy_power_on() on the error path. Simplify the code by moving the single call to the end of the function. No functional change intended. Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-7-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Drop TMDS rate setup workaroundCristian Ciocaltea
Since commit ba9c2fe18c17 ("drm/rockchip: dw_hdmi_qp: Switch to phy_configure()") the TMDS rate setup doesn't rely anymore on the unconventional usage of the bus width, instead it is managed exclusively through the HDMI PHY configuration API. Drop the now obsolete workaround to retrieve the TMDS character rate via phy_get_bus_width() during power_on(). Tested-by: Thomas Niederprüm <dubito@online.de> Tested-by: Simon Wright <simon@symple.nz> Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-6-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changesCristian Ciocaltea
Any changes to the PHY link rate and/or color depth done via the HDMI PHY configuration API are not immediately programmed into the hardware, but are delayed until the PHY usage count gets incremented from 0 to 1, that is when it is powered on or when the PLL clock exposed through the CCF API is prepared, whichever comes first. Since the clock might remain in prepared state after subsequent PHY config changes, the programming can also be triggered via clk_ops.set_rate(). However, from the clock consumer perspective (i.e. VOP2 display controller), the (pixel) clock rate doesn't vary with bpc, as that is handled internally by the PHY and reflected in the TDMS character rate only. As a consequence, changing the bpc while preserving the modeline may lead to out-of-sync issues between CCF and HDMI PHY config state, because the .set_rate() callback is not invoked when clock rate remains constant. This may also happen when the PHY PLL has been pre-programmed by an external entity, e.g. the bootloader, which is actually a regression introduced by the recent FRL-related changes. Introduce a pll_config_dirty flag to keep track of uncommitted PHY config changes and use it in clk_ops.determine_rate() to invalidate the current clock rate (as known by CCF) and, consequently, ensure those changes are programmed into hardware via clk_ops.set_rate(). Moreover, proceed with a similar fix in phy_ops.power_on() callback, to handle the scenario where the CCF API is not used due to operating in FRL mode, while the clock is still in a prepared state and thus preventing rk_hdptx_phy_consumer_get() to apply the updated PHY configuration. Fixes: de5dba833118 ("phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL support") Fixes: 9d0ec51d7c22 ("phy: rockchip: samsung-hdptx: Add high color depth management") Tested-by: Thomas Niederprüm <dubito@online.de> Tested-by: Simon Wright <simon@symple.nz> Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-5-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Fix rate recalculation for 3.2GHz FRLCristian Ciocaltea
rk_hdptx_phy_clk_calc_rate_from_pll_cfg() is currently unable to handle cascade mode for the 3.2GHz FRL operating mode, as it relies solely on LCPLL_LCVCO_MODE_EN_MASK to determinate the rate from the rk_hdptx_frl_lcpll_cfg array. Since there is no entry for this particular rate, the function returns 0. This is the only rate which requires LC_REF_CLK_SEL to be set in GRF_HDPTX_CON0, hence extend the FRL matching accordingly. Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com?part=1 Fixes: de5dba833118 ("phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL support") Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-4-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Guard against clk rate integer underflowCristian Ciocaltea
The 'fout' subtraction in rk_hdptx_phy_clk_calc_rate_from_pll_cfg() could result in an integer underflow, if the hardware registers are misconfigured or contain uninitialized values, such that the computed sigma-delta modulator offset sdm exceeds the base frequency fout. This might lead to an absurdly high clock rate being returned to the Common Clock Framework, with unpredictable effects on downstream clk consumers. Provide the necessary sanitization to avoid trusting the hardware state. Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260611235702.0E9691F000E9@smtp.kernel.org/ Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-3-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Prevent divide-by-zero when computing clk rateCristian Ciocaltea
Calculating 'sdm' fraction in rk_hdptx_phy_clk_calc_rate_from_pll_cfg() could trigger a divide-by-zero, as it uses div_u64() with a denominator read directly from hardware: the values ropll_hw.sdm_deno, ropll_hw.sdc_deno, ropll_hw.sdc_n, and ropll_hw.sdc_num are populated from PLL registers which, in theory, could be left by the bootloader uninitialized/misconfigured. Provide the necessary sanitization to avoid trusting the hardware state. Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com?part=1 Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config") Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-2-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpcCristian Ciocaltea
The PHY PLL can be programmed by an external component, e.g. the bootloader, just before the recalc_rate() callback is invoked during devm_clk_hw_register() in the probe path. Therefore rk_hdptx_phy_clk_recalc_rate() finds the PLL enabled and attempts to compute the clock rate, while making use of the bpc value from the HDMI PHY configuration, which always defaults to 8 because phy_configure() was not run at that point. As a consequence, the (re)calculated rate is incorrect when the actual bpc was higher than 8. Do not rely on any of the hdmi_cfg members when computing the clock rate and, instead, read the required input data (i.e. bpc), directly from the hardware registers. Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config") Tested-by: Thomas Niederprüm <dubito@online.de> Tested-by: Simon Wright <simon@symple.nz> Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS Reviewed-by: Andy Yan <andyshrk@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260811-hdptx-clk-fixes-v6-1-75bca0ee5753@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-11docs: conf.py: fix the 'utf-8' typoRandy Dunlap
"encoding" should be 'utf-8'. Fix the typo. Fixes: 7ea9a550f710 ("docs: conf.py: several coding style fixes") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260806051115.1235789-1-rdunlap@infradead.org>
2026-08-11doc tools: fix 'path' typosRandy Dunlap
Correct "patch" or "patches" to "path" or "paths" in comments. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260806055634.1293294-1-rdunlap@infradead.org>
2026-08-11Documentation: real-time: Add kernel configuration guideAhmed S. Darwish
Add a configuration guide for real-time kernels. List all Kconfig options that are recommended to be either enabled or disabled. Explicitly add a table of contents at the top of the document, so that all the options can be seen in a glance. Whenever appropriate, link to other kernel guides; e.g. cpuidle, cpufreq, power management, workqueues, and no_hz. Add a summary at the end of the document warning users that there is no "one size fits all solution" for configuring a real-time system. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260804141541.747704-2-darwi@linutronix.de>
2026-08-11docs: python: abi_regex: convert adjacent index placeholdersAlison Schofield
While validating recent CXL ABI documentation updates with get_abi.py, every decoderX.Y entry was reported as undocumented. The placeholder conversion mishandles adjacent index placeholders, producing patterns that cannot match the corresponding sysfs paths. As a result, valid ABI entries are reported as undocumented. Handle adjacent placeholders independently so generated patterns match the documented paths. This fixes decoderX.Y entries in the CXL ABI and other ABI documentation that uses the same naming convention. Signed-off-by: Alison Schofield <alison.schofield@intel.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <cc893dca3aaa3ec833ba70d1f32c3e7342b7faf2.1786139549.git.alison.schofield@intel.com>
2026-08-11docs: python: abi_regex: catch the right exception for a bad regexAlison Schofield
While validating recent CXL ABI documentation updates with get_abi.py, the 'undefined' mode was found to abort instead of reporting undocumented ABI entries. Older Python releases raise re.error, while newer releases expose re.PatternError. Catching the compatible re.error exception handles both cases. Use re.error so the scan continues and reports the remaining results. Signed-off-by: Alison Schofield <alison.schofield@intel.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <9f6fa7a9aa6ba9a26b484b911976713356b3fd44.1786139549.git.alison.schofield@intel.com>
2026-08-11drm/sched: Mark fair policy as experimentalTvrtko Ursulin
Mark the fair policy as experimental until reported regressions are addressed. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Luke.Wildhardt@proton.me Cc: Matthew Brost <matthew.brost@intel.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Philipp Stanner <phasta@kernel.org> Cc: Christian König <ckoenig.leichtzumerken@gmail.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260811163139.99746-20-tvrtko.ursulin@igalia.com