summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-14thermal: intel: Add syscore callbacks for suspend and resumeRicardo Neri
Directed package-level thermal interrupts are serviced by a single CPU per package. These handler CPUs are selected at boot through the CPU hotplug infrastructure. This mechanism is sufficient to restore the directed interrupt configuration when resuming from suspend for non-boot packages. It also keeps the handler-tracking array updated. For the boot package, CPU0 is chosen during boot because its CPU hotplug online callback runs first. However, this callback is not invoked on resume. The directed package-level interrupt configuration for the boot package is not restored. Add a syscore resume callback to re-enable directed package-level interrupts for this package. Disabling directed interrupts during suspend is required to keep the handler-tracking array in a consistent state for the boot package, allowing the correct configuration to be restored on resume. The resume callback must busy-wait for hardware acknowledgment of the directed interrupt setup. Otherwise, the handler-tracking array could be left in an inconsistent state. This implies running with interrupts disabled for up to 15ms, though in practice it takes less than 1ms. Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Link: https://patch.msgid.link/20260613-rneri-directed-therm-intr-v3-5-3a26d1e47fc8@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-14thermal: intel: Enable the Directed Package-level Thermal InterruptRicardo Neri
Package-level thermal interrupts are broadcast to all online CPUs within a package, even though only one CPU needs to service them. This results in unnecessary wakeups, lock contention, and corresponding performance and power-efficiency penalties. When supported by hardware, a CPU requests to receive directed package- level thermal interrupts by setting a designated bit in IA32_THERM_INTERRUPT. The operating system must then verify that hardware has acknowledged this request by checking a designated bit in IA32_PACKAGE_THERM_STATUS. Enable directed package-level thermal interrupts on one CPU per package using the CPU hotplug infrastructure. The first CPU of a package that comes online will handle the interrupt. If the handling CPU goes offline, select a new CPU. Temporarily enable directed interrupts on both the current and new CPU until hardware acknowledges the new selection, then disable them on the outgoing CPU. Systems without directed-interrupt support continue to broadcast the package-level interrupt to all CPUs. Also, add a rollback mechanism in the CPU hotplug online callback to fall back to broadcast mode if the directed-interrupt acknowledgment fails in any package. This is most important during boot, when all CPUs in a package come online and would otherwise keep retrying on faulty hardware. A complete rollback is not needed in the CPU hotplug offline callback since at that point the hardware is known to work. While here, update an inline comment to point to the correct volume of the Intel Software Developer's Manual. Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Link: https://patch.msgid.link/20260613-rneri-directed-therm-intr-v3-4-3a26d1e47fc8@linux.intel.com [ rjw: Rebased on top of 7.2-rc2 ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-14io_uring/fs: check unused sqe fields for unlinkatYi Xie
Zero check unused SQE fields addr3 and pad2 for unlinkat. They're not needed now, but could be used sometime in the future. Signed-off-by: Yi Xie <xieyi@kylinos.cn> Reviewed-by: Gabriel Krisman Bertazi <krisman@suse.de> Link: https://patch.msgid.link/20260714030306.64820-1-xieyi@kylinos.cn Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-14arm64: dts: apple: Add pmgr-misc nodes to t60xxSasha Finkelstein
Adds the PMGR misc control nodes for M1/2 Pro/Max/Ultra series devices. Reviewed-by: Sven Peter <sven@kernel.org> Signed-off-by: Sasha Finkelstein <k@chaosmail.tech> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260705-pmgr-misc-v3-3-51b75fed6f73@chaosmail.tech Signed-off-by: Sven Peter <sven@kernel.org>
2026-07-14iwlwifi: dvm: add missing cleaup for on error pathHaoxiang Li
In iwlagn_tx_agg_start(), call iwlagn_dealloc_agg_txq() to clear bit on error path. Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn> Link: https://patch.msgid.link/20260401030555.541685-1-lihaoxiang@isrc.iscas.ac.cn Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14soc: apple: Add driver for Apple PMGR misc controlsHector Martin
Apple SoCs have PMGR blocks that control a bunch of power-related features. Besides the existing device power state controls (which are very uniform and handled by apple-pmgr-pwrstate), we also need to manage more random registers such as SoC-wide fabric and memory controller power states, which have a different interface. Add a driver for these kitchen sink controls. Right now it implements fabric and memory controller power state switching on system standby/s2idle, which saves about 1W of power or so on t60xx platforms. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Sven Peter <sven@kernel.org> Co-developed-by: Sasha Finkelstein <k@chaosmail.tech> Signed-off-by: Sasha Finkelstein <k@chaosmail.tech> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260705-pmgr-misc-v3-2-51b75fed6f73@chaosmail.tech Signed-off-by: Sven Peter <sven@kernel.org>
2026-07-14dt-bindings: soc: apple: Add Apple PMGR misc controlsSasha Finkelstein
Certain Apple SoCs include additional PMGR power states that are controlled via a different "misc" control block. On existing SoCs, this includes the fabric and memory controller state. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Sasha Finkelstein <k@chaosmail.tech> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260705-pmgr-misc-v3-1-51b75fed6f73@chaosmail.tech Signed-off-by: Sven Peter <sven@kernel.org>
2026-07-14KVM: selftests: Fix a spelling error in an xapic_ipi_test commentWang Yan
Fix typo "usefull" -> "useful" in xAPIC IPI test comment. Signed-off-by: Wang Yan <wangyan01@kylinos.cn> Link: https://patch.msgid.link/20260702015739.367597-1-wangyan01@kylinos.cn Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-14drm: ensure blend mode supported if pixel format with alpha exposedLeandro Ribeiro
Before "drm/drm_blend: allow blend mode property without PREMULTI", userspace would have to assume that only PREMULTI was supported by drivers that didn't expose the blend mode property. But now userspace shouldn't rely on that, as they can't count with drivers always supporting PREMULTI. Warn if a driver exposes pixel formats with alpha but doesn't expose the blend mode property. This way userspace doesn't have to guess. Drivers triggering this warning must be fixed. Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260526181700.25310-3-leandro.ribeiro@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-07-14drm/drm_blend: allow blend mode property without PREMULTILeandro Ribeiro
Some hardware only supports the COVERAGE blend mode and lacks PREMULTI support entirely. DRM currently requires that PREMULTI is present when creating a blend mode property, which prevents such drivers from being properly upstreamed. Remove this restriction and allow drivers to create a blend mode property without PREMULTI, enabling support for hardware that implements only COVERAGE blend mode. This does not introduce a regression, as no existing upstream drivers expose only COVERAGE. However, userspace that wants to support such kind of hardware in the future will have to check the supported blend modes instead of assuming PREMULTI is always supported. Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260526181700.25310-2-leandro.ribeiro@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-07-14io_uring/kbuf: free the replaced iovec after a successful growJaeyeong Lee
The provided-buffer validation fix deferred freeing a cached iovec until validation completed. However, the deferred free uses arg->iovs. After a grow, that points to the newly allocated array. Without a grow, it points to the cached array that remains in use. This leaves the caller with a dangling iovec in both cases and can result in repeated frees. Only free org_iovs when arg->iovs actually replaced it. Fixes: cd053d788c3f ("io_uring: fix dangling iovec after provided-buffer bundle grow failure") Assisted-by: Codex:gpt-5.3-codex-spark Signed-off-by: Jaeyeong Lee <iostreampy@proton.me> Link: https://patch.msgid.link/20260712142612.188695595-iostreampy@proton.me Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-14wifi: iwlwifi: dvm: fix memory leak in iwl_op_mode_dvm_start()Dawei Feng
In iwl_op_mode_dvm_start(), jumping to out_free_eeprom currently bypasses the out_free_eeprom_blob label. Consequently, error paths triggered after successfully parsing the EEPROM free priv->nvm_data but leak priv->eeprom_blob. Fix this memory leak by reordering the error handling labels so that out_free_eeprom falls through to out_free_eeprom_blob. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc6. An x86_64 allyesconfig build showed no new warnings. As we do not have supported Intel DVM wireless hardware and firmware to test with, no runtime testing was able to be performed. Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn> Link: https://patch.msgid.link/20260624084404.570703-1-dawei.feng@seu.edu.cn Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14x86/entry/fred: Encode frame pointer on entryDavid Stevens
Add missing ENCODE_FRAME_POINTER macro invocation into FRED_ENTER macro, to prevent the unwinder from encountering a NULL stack frame pointer when CONFIG_UNWINDER_FRAME_POINTER is enabled Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") Signed-off-by: David Stevens <stevensd@google.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com> Link: https://patch.msgid.link/20260424191456.2679717-12-stevensd@google.com
2026-07-14wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rateBaochen Qiang
ath11k can receive HT/VHT/HE frames whose reported MCS is above the maximum that can be expressed in the corresponding mac80211 rate space (e.g. an HE frame reported with MCS 12, while HE tops out at MCS 11). The frame itself is valid and decodes correctly, but for such a frame ath11k_dp_rx_h_rate() leaves rx_status->rate_idx set to the out-of-range value and never assigns rx_status->encoding, so it stays RX_ENC_LEGACY from the ath11k_dp_rx_h_ppdu() initialization. Once that frame reaches mac80211 it trips the rate sanity check and the frame is dropped with a splat: ath11k_pci 0000:03:00.0: Received with invalid mcs in HE mode 12 WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:5433 ieee80211_rx_list+0xb0a/0xe90 [mac80211] Dropping the frame would discard otherwise valid data, so instead cap the reported MCS to the maximum the rate space can express and deliver the frame. Set rx_status->encoding before the range check and assign rate_idx from the capped value, so a frame with an out-of-range MCS no longer leaves partial or bogus rate metadata behind. Also downgrade the logging level since they are not treated as invalid frames now. The only loss is that such a frame is reported as the capped MCS in the rx rate statistics. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260701-ath11k-invalid-he-mcs-v1-1-7d963080c079@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-14wifi: ath12k: add QMI capability negotiation for dynamic memory modeAaradhana Sahu
On AHB platforms, firmware operates in two modes: fixed-memory mode where firmware uses hardcoded addresses for memory regions such as BDF and does not request HOST_DDR memory from the host, and dynamic-memory mode where firmware expects the host to provide memory addresses including HOST_DDR after the Q6 read-only region and relies on host allocation for all memory types. Introduce QMI capability negotiation to support both modes. Add a new QMI PHY capability flag dynamic_ddr_support which is advertised by firmware to indicate it supports dynamic memory mode. When the host detects this capability, set the dynamic_mem_support flag in the host capability message to signal the host is ready to provide dynamic memory allocation. This triggers firmware to send the HOST_DDR memory request and use the host-provided address. For backward compatibility, if firmware doesn't advertise dynamic_ddr_support, the firmware continues to operate in fixed-memory mode where firmware uses predefined addresses. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Link: https://patch.msgid.link/20260701041611.3077185-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-14wifi: ath12k: fix rx_mpdu_start layout for QCC2072Wei Zhang
QCC2072's rx_mpdu_start TLV has a different field layout from QCN9274. Reusing struct rx_mpdu_start_qcn9274 in hal_rx_desc_qcc2072 causes the RX datapath to read the wrong offsets for info2, info4, pn[] and phy_ppdu_id, producing corrupted sequence number, PN, ppdu_id and mpdu-info flags (encrypted, fragment, addr2/addr4 valid). Add a dedicated struct rx_mpdu_start_qcc2072 that matches the actual hardware descriptor layout, and use it in hal_rx_desc_qcc2072. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00188-QCACOLSWPL_V1_TO_SILICONZ-1 Fixes: 28badc78142e ("wifi: ath12k: add HAL descriptor and ops for QCC2072") Signed-off-by: Wei Zhang <wei.zhang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260629061529.1993932-1-wei.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-14wifi: ath12k: Reduce RX SRNG interrupt timer threshold to 200usThiraviyam Mariyappan
Currently when RX traffic is low or intermittent, the RX SRNG interrupt mitigation logic defers packet processing for up to 500us via HAL_SRNG_INT_TIMER_THRESHOLD_RX. This causes excessive RX servicing delay, leading to increased end-to-end latency and degraded TCP performance in low-concurrency scenarios. In single-client single-stream TCP tests using 5G EHT160 (NSS 2x2) mode, throughput drops to ~400 Mbps DL and UL instead of the expected ~600 Mbps. In addition, UDP UL end-to-end latency measured in 5G VHT80 (NSS 4x4) mode increases by up to ~48% (~570us versus ~270us) across frame sizes from 76 to 1518 bytes in uplink and bidirectional traffic, indicating delayed RX servicing under sparse traffic conditions. To address this issue, reduce the RX SRNG interrupt timer threshold from 500us to 200us so that received packets are serviced more promptly under low-rate and intermittent RX traffic. With this change, single-client single-stream TCP throughput in EHT160 is restored to expected levels ~600 Mbps TCP DL/UL and UDP UL end-to-end latency in VHT80 returns to baseline values ~270us across all tested frame sizes. Under high RX load, no throughput regression is observed, as RX rings are already serviced frequently. The primary implication is a modest increase in RX interrupt frequency under low traffic, with no observed functional, stability, or performance regressions on tested platforms. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01181-QCAHKSWPL_SILICONZ-1 Signed-off-by: Thiraviyam Mariyappan <thiraviyam.mariyappan@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260622062324.758533-1-thiraviyam.mariyappan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-14wifi: ath12k: Fix ath12k_wifi7_mac_op_tx() style issuesJeff Johnson
Commit e47d6c9bb416 ("wifi: ath12k: Advertise multicast Ethernet encapsulation offload support") introduced a few style issues. ath12k-check reports: drivers/net/wireless/ath/ath12k/wifi7/hw.c:1042: line length of 92 exceeds 90 columns And automated review did not like one if/else that did not use braces for a single statement that also included a block comment. Fix these issues. Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260711-ath12k_wifi7_mac_op_tx-line-length-v1-1-10e4899b98ef@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-14wifi: ath12k: fix MLO peer delete raceBaochen Qiang
ath12k_peer_mlo_link_peers_delete() sends WMI peer_delete for every link before waiting for any peer_unmap / peer_delete_resp event. The shared per-radio completion ar->peer_delete_done could not disambiguate which peer a response was for: every call to ath12k_peer_delete_send() did reinit_completion(&ar->peer_delete_done), so when an event for the first link arrived between two sends it raised the count to 1 and the second send promptly cleared it; the wait for the second link then timed out with Timeout in receiving peer delete response Replace the shared completion with a per-radio waiter list, with each pending ath12k_peer_delete() caller queueing an ath12k_peer_delete_wait carrying its (vdev_id, addr) and a private struct completion. ath12k_peer_delete_resp_event() matches the response against the list under ar->data_lock and signals the matching waiter. Also correct the endian conversion in ath12k_peer_delete_resp_event() logging, and add the missing \n in some logging. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Fixes: 8e6f8bc28603 ("wifi: ath12k: Add MLO station state change handling") Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260629-ath12k-mlo-peer-delete-race-v2-2-362b25590d19@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-14wifi: ath12k: fix dp_link_peer dangling references on AP vdev rollbackBaochen Qiang
ath12k_mac_vdev_create() for an AP vdev creates the bss self-peer via ath12k_peer_create(), which finishes by calling ath12k_dp_link_peer_assign() to publish the dp_link_peer in the dp_hw->dp_peers[peerid_index] RCU table, in the dp_peer's link_peers[] array, and in the per-addr rhashtable. If a step after ath12k_peer_create() fails the function jumps to err_peer_del, which open-codes a WMI peer_delete and waits for the unmap / delete_resp events. The wait_for_peer_delete_done() path relies on ath12k_dp_link_peer_unmap_event() freeing the dp_link_peer when the unmap arrives, but err_peer_del never calls ath12k_dp_link_peer_unassign() first. The published references in the dp_hw RCU table, dp_peer->link_peers[] and the rhashtable are left pointing at the dp_link_peer that unmap_event then frees, producing dangling pointers and use-after-free on subsequent lookups. Replace the open-coded sequence with a call to ath12k_peer_delete(), which already does ath12k_dp_link_peer_unassign() before sending the WMI command. This drops the published references before the dp_link_peer is freed, in the same order as the normal teardown path in ath12k_mac_remove_link_interface(). Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Fixes: 5525f12fa671 ("wifi: ath12k: Attach and detach ath12k_dp_link_peer to ath12k_dp_peer") Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260629-ath12k-mlo-peer-delete-race-v2-1-362b25590d19@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-14wifi: ath12k: Switch to generic PAS TZ APIsSumit Garg
Switch ath12k client driver over to generic PAS TZ APIs. Generic PAS TZ service allows to support multiple TZ implementation backends like QTEE based SCM PAS service, OP-TEE based PAS service and any further future TZ backend service. Acked-by: Jeff Johnson <jjohnson@kernel.org> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260702115835.167602-13-sumit.garg@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-14wifi: iwlwifi: fw: Fix spelling typo in error-dump.hPraveen Rajendran
Correct a minor grammatical error inside the kernel-doc comments of error-dump.h where "configuration" was misspelled as "configuraiton". Signed-off-by: Praveen Rajendran <praveenrajendran2009@gmail.com> Link: https://patch.msgid.link/20260703140757.3372-1-praveenrajendran2009@gmail.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14Documentation: PCI: Fix sysfs-bus-pci typoD'Orus Tsitera
Replace "similiar" with "similar" in Documentation/ABI/testing/sysfs-bus-pci. Signed-off-by: D'Orus Tsitera <dorustsitera@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260713-docs-fix-similiar-v1-1-257e25150346@gmail.com
2026-07-14wifi: iwlwifi: Clean dangling pointer in tx pathBen Greear
If iwl_txq_gen2_build_tfd fails, we return -1, which will cause calling code to dispose of the skb one way or another. Remove any reference to that skb from the txq entries so that nothing will try to access it later. Signed-off-by: Ben Greear <greearb@candelatech.com> Link: https://patch.msgid.link/20260214190509.2098565-1-greearb@candelatech.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mvm: d3: validate D3 resume notification payloadsEmmanuel Grumbach
D3 resume notification handlers read firmware notification fields before validating that the payload contains the complete fixed structure. This causes buffer underread on malformed or truncated notifications. Move payload length validation to occur before any field access in: - iwl_mvm_parse_wowlan_info_notif: validate before reading num_mlo_link_keys - iwl_mvm_wait_d3_notif D3_END handler: validate before reading flags Assisted-by: GitHub Copilot <copilot@github.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.762193753434.I148991b8136cc5042fa08b5faf7b57d38aa2fb47@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: pcie: null RX pointers after freeEmmanuel Grumbach
When iwl_pcie_tx_init() fails after RX init, nic init unwinds via iwl_pcie_rx_free(). The freed RX members stayed non-NULL on the live transport object, so later teardown or retry could touch stale RX state. Set rx_pool, global_table, rxq, and alloc_page to NULL after free to make repeated cleanup and retry paths safe. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.33e8978d8b36.Ibaedd4b0ce01405b940de7b90223b6d2c5136ffd@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mvm: fix sched scan IE sizingEmmanuel Grumbach
Scheduled scan built the probe request before iwl_mvm_scan_fits(), so oversized IEs could be copied into the fixed preq buffer before length validation. Move iwl_mvm_build_scan_probe() after the fits check. Also advertise max_sched_scan_ie_len using iwl_mvm_max_scan_ie_len() so userspace limits account for driver-inserted DS/TPC bytes. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Link: https://patch.msgid.link/20260714141909.53d2722c79e7.Iebb922efa6173c92f14cd8aa8b4e7f372c0a0fb7@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mld: clear tzone on failEmmanuel Grumbach
iwl_mld_thermal_zone_register() stores the thermal zone pointer in mld->tzone before calling thermal_zone_device_enable(). If enable fails, the code unregisters the zone but leaves mld->tzone stale, so iwl_mld_thermal_zone_unregister() can unregister it again. Clear mld->tzone after unregister in the error path. While at it remove a pointless if in iwl_mld_thermal_zone_unregister after we've alredy checked the tzone pointer is not NULL. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.595dcb8cb7fe.I8125e4a2eeb0390798e3f4074c62c00443eda8e8@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mvm: validate mac_link_id in session protect notifEmmanuel Grumbach
Check the mac_id before accessing the vif_id_to_mac array. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.547ea470e686.I931445ae6f37bf0e1ef6f112c811712fc48af9c9@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mvm: validate sta_id in BA window status notifEmmanuel Grumbach
BA_WINDOW_STATUS_NOTIFICATION_ID extracts a 5-bit sta_id from the firmware notification and uses it to index fw_id_to_mac_id[] without bounds checking. Validate sta_id before array access to prevent out-of-bounds indexing. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.2e97f337f3cb.Ic3f0f404082ccdea13809a3c0b70e0f5417e1037@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mvm: validate sta_id in TLC notifEmmanuel Grumbach
TLC_MNG_UPDATE_NOTIF uses firmware-provided sta_id to index fw_id_to_link_sta[] and fw_id_to_mac_id[]. Validate sta_id before array access to avoid out-of-bounds indexing. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.1ce54794c1f8.I275fd4c1165bf42fb17516c550dd8813a2b8286e@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mvm: validate MCC header before n_channelsEmmanuel Grumbach
MCC response parsing read n_channels from v8/v4/v3 response variants before ensuring the payload contained the fixed response header. Add a minimum payload-length check for each response version before reading n_channels, and keep the existing exact-size validation for the channels array payload. Assisted-by: GitHub Copilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.cb2cef3d3e7e.Iee7b48614289da576de842157ad3730b7589a4b1@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mvm: parse beacon notif per layoutEmmanuel Grumbach
The beacon TX notification can arrive in different layouts, and fields must be read only after selecting the expected format. Parse gp2 and TSF from the matching notification structure in each branch, and keep using the parsed gp2 for CSA countdown and debug output. Drop the obsolete cached gp2 field. Assisted-by: GitHub Copilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.cc8aa937f8e5.I921f8dadcb20cb73e8283e1b8546e1778205411f@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mld: validate reorder BAIDEmmanuel Grumbach
Reject BAIDs >= IWL_MAX_BAID before indexing fw_id_to_ba. This prevents out-of-bounds access on malformed notifications. Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.07ea823b8eea.Ica915fa0cce0427bf5e3420ae933f57118fedf86@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mvm: fix the FCS truncation logic in d3Emmanuel Grumbach
Fix a harmless mistake in the wake packet management code in the d3 wakeup flow. If the FCS is truncated, we want to detect it, but we cleared the icvlen before updating the truncated variable that holds the number of bytes having been truncated. Fix that. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.369588f93c6b.I1a4d13f276c7e75514ab2032ae387873337470b8@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mld: don't parse a notif before checking its lengthEmmanuel Grumbach
In order to compure the size of the iwl_mcc_update_resp which has a variable length, we need to know the number of channels. In order to read the number of channels, we must first check the payload is long enough to read at least that. Add this check. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.c2f644919011.Ic579e9935b92a674c96ccc44713140b5b4bc5d10@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mld: fix an off-by-1 boundary checkEmmanuel Grumbach
Before looking at the 11th byte, check the length is big enough. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260714141909.336b527e3fc6.I6fe839f4e70d673632fd7ca757e81827af87b029@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mvm: fix an off-by-1 boundary checkEmmanuel Grumbach
Before looking at the 11th byte, check the length is big enough. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Link: https://patch.msgid.link/20260714141909.d22bf52a18d0.If0ef6612a67cca671428b06dbdeec68549e50ae6@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14wifi: iwlwifi: mvm: verify scan id reported by firmwareAvraham Stern
The scan id reported by firmware in scan complete notification is used as an index to the scan status array. Verify the reported id does not exceed the array size. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Link: https://patch.msgid.link/20260714141909.fdf31f494f1c.I70d01ed2023f6584fb23ea8ab344a93d222cc4c0@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-14hfs: don't re-dirty MDB buffers after a write failureViacheslav Dubeyko
hfs_mdb_commit() and hfs_mdb_close() keep the MDB and alternate-MDB buffer heads (mdb_bh, alt_mdb_bh) pinned for the lifetime of the mount and write into them in place. If a write against the backing device fails, the block layer clears BH_Uptodate on the buffer (end_buffer_write_sync(), fs/buffer.c) to mark its contents as no longer trustworthy. !buffer_uptodate(bh) WARNING: fs/buffer.c:1093 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1093, CPU#0: syz.1.1033/6784 Modules linked in: CPU: 0 UID: 0 PID: 6784 Comm: syz.1.1033 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:mark_buffer_dirty+0x299/0x410 fs/buffer.c:1093 Code: 4c 89 f7 e8 f9 0d d9 ff 49 8b 3e be 40 00 00 00 5b 41 5c 41 5e 41 5f 5d e9 d4 5e fb ff e8 af e7 69 ff eb 8c e8 a8 e7 69 ff 90 <0f> 0b 90 e9 a5 fd ff ff e8 9a e7 69 ff 90 0f 0b 90 e9 cf fd ff ff RSP: 0018:ffffc90005d379a8 EFLAGS: 00010293 RAX: ffffffff825c9ae8 RBX: ffff8880123aa700 RCX: ffff888034a30000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002 RBP: 1ffff1100a45f401 R08: ffff8880123aa707 R09: 1ffff110024754e0 R10: dffffc0000000000 R11: ffffed10024754e1 R12: dffffc0000000000 R13: ffff8880522fa668 R14: ffff888045ba945b R15: ffff888045ba9400 FS: 000055556b366500(0000) GS:ffff88808c54e000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31a63fff CR3: 0000000034b1d000 CR4: 0000000000352ef0 Call Trace: <TASK> hfs_mdb_commit+0x503/0x1160 fs/hfs/mdb.c:309 hfs_sync_fs+0x1d/0x30 fs/hfs/super.c:38 sync_filesystem+0x1cf/0x230 fs/sync.c:66 fs_bdev_sync+0x2c/0x50 fs/super.c:1433 blkdev_flushbuf block/ioctl.c:520 [inline] blkdev_common_ioctl+0x12e1/0x3250 block/ioctl.c:658 blkdev_ioctl+0x528/0x740 block/ioctl.c:791 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1d9239de59 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fffd0ece148 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f1d92625fa0 RCX: 00007f1d9239de59 RDX: 0000000000000000 RSI: 0000000000001261 RDI: 0000000000000004 RBP: 00007f1d92433e6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f1d92625fac R14: 00007f1d92625fa0 R15: 00007f1d92625fa0 </TASK> This was found by fuzzing an HFS image on a loop device backed by a memfd; under memory pressure the shmem write-back path returned -ENOSPC (mm/shmem.c, shmem_acct_blocks()), which surfaced as a plain write error on the block device. The call path: ioctl(BLKFLSBUF) -> blkdev_common_ioctl() -> sync_filesystem() -> hfs_sync_fs() -> hfs_mdb_commit(). Check buffer_uptodate() on mdb_bh/alt_mdb_bh before dirtying them. If either has gone stale, mark the volume read-only and skip the write instead of asserting on it. Also, hfs_mdb_commit() returns -EIO error code in such situation. As a result, hfs_sync_fs() can report the failure instead of always returning 0. The sync()/fsync()/BLKFLSBUF now observe -EIO instead of silently succeeding while the volume goes read-only underneath them. Reported-by: syzbot+c149ad75e9633be0c1ad@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c149ad75e9633be0c1ad cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260709225001.473320-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-07-14hfsplus: fix error code when writing beyond volume capacityViacheslav Dubeyko
The xfstests' test-case generic/564 fails for the case of HFS+ file system. Test-case expects that file system driver reports -EFBIG error code in the case if there is the effort to write beyond 8TiB. However, HFS+ file system driver returns -ENOSPC instead. The root cause is that hfsplus_fill_super() sets s_maxbytes as MAX_LFS_FILESIZE. VFS therefore considers the write position valid and calls into the filesystem. Because HFS+ does not support holes, cont_write_begin() zero-fills the entire intermediate range from the current end-of-file to the target offset. On a small test volume this exhausts free space long before any block-number overflow is detected, producing -ENOSPC instead of -EFBIG. This patch fixes the issue by adding a bounds check at the top of hfsplus_write_begin(). If the requested write position is at or beyond the actual capacity of the volume in bytes, return -EFBIG immediately before cont_write_begin() is entered and before any zero-fill I/O is attempted. sudo ./check generic/564 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.2.0-rc1-dirty #50 SMP PREEMPT_DYNAMIC Fri Jul 3 16:22:27 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/564 13s ... 43s Ran: generic/564 Passed all 1 tests cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260706221738.140271-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-07-14hfs: fix error code when writing beyond volume capacityViacheslav Dubeyko
Likewise HFS+, HFS has the same issue of returning the -ENOSPC error code instead of -EFBIG in the case if there is the effort to write beyond 8TiB. The root cause is that hfs_fill_super() sets s_maxbytes as MAX_LFS_FILESIZE. VFS therefore considers the write position valid and calls into the filesystem. Because HFS does not support holes, cont_write_begin() zero-fills the entire intermediate range from the current end-of-file to the target offset. On a small test volume this exhausts free space long before any block-number overflow is detected, producing -ENOSPC instead of -EFBIG. This patch fixes the issue by adding a bounds check at the top of hfs_write_begin(). If the requested write position is at or beyond the actual capacity of the volume in bytes, return -EFBIG immediately before cont_write_begin() is entered and before any zero-fill I/O is attempted. cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260706221804.140295-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-07-14hfsplus: validate thread record before delete key rebuildKyle Zeng
hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName. That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name. A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation. Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name. Share the thread-record-type helper between hfsplus_find_cat() and hfsplus_delete_cat(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: Codex:gpt-5.6 Signed-off-by: Kyle Zeng <kylebot@openai.com> Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260709010203.49664-1-kylebot@openai.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-07-14hfs: validate catalog CNIDs before instantiating inodesDavid Maximiliano Hermitte
hfs_cat_find_brec() first resolves a catalog thread record by CNID and then looks up the corresponding catalog record by parent/name. On a corrupted filesystem image, the second lookup may find a record whose CNID does not match the CNID that was requested. Validate the record found by the second lookup before returning it. Read the already-found record with hfs_bnode_read(), require the exact fixed size for file and directory records, reject other record types, and verify that the stored CNID matches the requested CNID. Also validate reserved CNIDs in hfs_read_inode() before populating the inode, propagate hfs_read_inode() failures from the resource-fork lookup path, and reject bad resource-fork and root inodes. Keep hfs_write_inode() unchanged, so corrupted catalog records are rejected before reaching its existing reserved-CNID BUG() path. Reported-by: syzbot+97e301b4b82ae803d21b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=97e301b4b82ae803d21b Cc: George Anthony Vernon <contact@gvernon.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: David Maximiliano Hermitte <davemadmaxxx@gmail.com> Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260708215636.73815-1-davemadmaxxx@gmail.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-07-14fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list()HE WEI(ギカク)
ni_create_attr_list() allocates a fixed buffer of al_aligned(record_size) (== record_size) bytes and then walks every attribute of the primary MFT record, writing one ATTR_LIST_ENTRY per attribute and advancing the cursor by le_size(name_len), with no check against the end of the buffer; the total size is only computed after the loop. A minimum-size resident attribute occupies SIZEOF_RESIDENT (0x18 = 24) bytes on disk, but an unnamed attribute expands to le_size(0) (0x20 = 32) bytes in the list. Because the number of attributes in a record is not bounded (mi_enum_attr() accepts arbitrarily many equal-type, nameless minimum-size attributes), a crafted record packed with such attributes produces a list larger than record_size and overflows the heap buffer. This is reachable from a crafted, loop-mounted NTFS image: opening the file and adding an attribute (e.g. via setxattr) drives ntfs_set_ea() -> ni_insert_resident() -> ni_insert_attr() -> ni_ins_attr_ext() -> ni_create_attr_list(). BUG: KASAN: slab-out-of-bounds in ni_create_attr_list+0xc48/0x1058 Write of size 4 at addr ffff000008984c00 by task setfattr/345 ni_create_attr_list+0xc48/0x1058 ni_ins_attr_ext+0x510/0x7c0 ni_insert_attr+0x3f8/0x70c ni_insert_resident+0xc8/0x3b0 ntfs_set_ea+0x66c/0xd28 ntfs_setxattr+0x4d8/0x5b0 __arm64_sys_setxattr+0xa4/0x124 Allocated by task 345: ni_create_attr_list+0x188/0x1058 The buggy address belongs to the cache kmalloc-1k of size 1024 (the write lands at object+1024). Size the buffer from the actual attributes instead of assuming a single record_size is always enough. Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Reported-by: HE WEI(ギカク) <skyexpoc@gmail.com> Signed-off-by: HE WEI(ギカク) <skyexpoc@gmail.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-07-14fs/ntfs3: cosmetic fixes and improvementsKonstantin Komarov
Get rid of unnecessary duplications, improve readability, clang-format the code. Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-07-14fs/ntfs3: widen inode/record number storage to u64Konstantin Komarov
NTFS inode and MFT record numbers are inherently 64-bit values, but several places stored them in 'unsigned long' (or CLST, a u32). On 32-bit architectures 'unsigned long' is only 32 bits wide, so the upper bits of a record reference are truncated. Store these values in u64 and update the associated format specifiers (%lx -> %llx) accordingly. Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-07-14drm/bridge: sii9234: use dev_err_probe where applicableHenrik Grimler
In case of error during resource acquisition the driver should print an error message only if it is not deferred probe. Use dev_err_probe helper to handle this, which will also record defer probe reason for debugging. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Henrik Grimler <henrik@grimler.se> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260602-exynos4-sii9234-driver-v4-2-9b2fc38e104a@grimler.se Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-14drm/bridge: sii9234: fix some typos in comments and messagesHenrik Grimler
Fix spelling and formatting so that the code is easier to follow, and so that it is more searchable. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Henrik Grimler <henrik@grimler.se> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260602-exynos4-sii9234-driver-v4-1-9b2fc38e104a@grimler.se Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-07-14drm/gpusvm: publish dpagemap early to avoid device mapping leak on errorHonglei Huang
drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review. Fixes: f70da6f99d4f ("drm/gpusvm: pull out drm_gpusvm_pages substructure") Cc: stable@vger.kernel.org Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260701062800.409248-4-honghuan@amd.com