summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-05-19dt-bindings: dmaengine: Add SpacemiT K3 DMA compatible stringGuodong Xu
Add the "spacemit,k3-pdma" compatible string for the SpacemiT K3 SoC. While the K3 PDMA IP reuses most of the design found on the earlier K1 SoC, a new compatible string is required because the DRCMR (DMA Request/Command Register) base address for extended DMA request numbers (>= 64) differs from the K1 implementation. Signed-off-by: Guodong Xu <guodong@riscstar.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Link: https://patch.msgid.link/20260518-k3-pdma-v6-1-67fdf319a8f8@linux.spacemit.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19wifi: ath12k: Add debugfs support to simulate incumbent signal interferenceAishwarya R
Add debugfs support to simulate incumbent signal interference from the host for testing purposes. The debugfs entry is created only for 6 GHz radio when firmware advertises the support through WMI_TLV_SERVICE_DCS_INCUMBENT_SIGNAL_INTERFERENCE_SUPPORT flag. Debugfs command: echo <interference_bitmap> > /sys/kernel/debug/ath12k/pci-000X/macX/simulate_incumbent_signal_interference Each bit in the interference_bitmap represents a 20 MHz segment. Bit 0 corresponds to the primary 20 MHz segment, regardless of its position within the operating bandwidth. Bit 1 represents the next adjacent 20 MHz segment, bit 2 the lower 20 MHz segment of the adjacent 40 MHz segment, and so on-progressing sequentially across the bandwidth.. Example: echo 0xF0 > /sys/kernel/debug/ath12k/pci-0002:01:00.0/mac0/simulate_incumbent_signal_interference This indicates that all the subchannels in the secondary 80 MHz segment were affected. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com> Signed-off-by: Amith A <amith.a@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260511040242.1351792-3-amith.a@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-05-19dt-bindings: dma: qcom,gpi: Document GPI DMA engine for Hawi SoCXueyao An
The Hawi GPI DMA engine follows the same programming model and register interface as previous generation of Qualcomm SoCs like kaanapali, glymur, and is fully compatible with earlier GPI DMA implementations. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Xueyao An <xueyao.an@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260401124028.589931-1-mukesh.ojha@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19wifi: ath12k: Add support for handling incumbent signal interference in 6 GHzAishwarya R
When incumbent signal interference is detected by an AP/mesh interface operating in the 6 GHz band, as mandated by the FCC, it is expected to vacate the affected channels. The firmware indicates the interference to the host using the WMI_DCS_INTERFERENCE_EVENT. To handle the new WMI event, first parse it to retrieve the interference information. Next, validate the interference-detected channel and the interference bitmap. The interference bitmap received from the firmware uses a mapping where bit 0 corresponds to the primary 20 MHz segment, regardless of its position within the operating bandwidth. Bit 1 represents the next adjacent 20 MHz segment, bit 2 the lower 20 MHz segment of the adjacent 40 MHz segment, and so on, progressing sequentially across the bandwidth. However, for userspace consumption via mac80211, this bitmap must be transformed into a standardized format such that each bit position directly maps to the corresponding sub-channel index within the operating bandwidth. Finally, indicate the transformed interference bitmap to mac80211, which then notifies userspace of the interference. Once the incumbent signal interference is detected, firmware suspends TX internally on the affected operating channel while userspace decides the mitigation action. Userspace is expected to trigger a channel switch or bandwidth reduction to mitigate the interference. Also, add a flag handling_in_progress to indicate that handling of interference is in progress. Set it to true after indicating to mac80211 about the interference. Reset the flag to false after the operating channel is switched by userspace. This prevents processing any further interference events when there is already a previous event being handled. Hence, further events are processed only after a channel switch request is received from userspace for the previous event. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com> Co-developed-by: Hari Chandrakanthan <quic_haric@quicinc.com> Signed-off-by: Hari Chandrakanthan <quic_haric@quicinc.com> Signed-off-by: Amith A <amith.a@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260511040242.1351792-2-amith.a@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-05-19dmaengine: qcom: bam_dma: Add support for BAM v2.0.0Kuldeep Singh
Add register offset table entry for bam v2.0.0 version found on kaanapali. Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260514-knp_qce-v2-2-890e3372eef8@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19dt-bindings: dma: qcom,bam-dma: Document BAM v2.0.0 compatibleKuldeep Singh
Document compatible string for bam v2.0.0 version found on kaanapali. BAM v2.0.0 differs from the earlier v1.7.X revision in terms of register layout and offsets, requiring a distinct compatible for correct hardware description. Also add a new example for BAM v2.0.0 to illustrate a more complete configuration than the existing v1.4 example. The new example covers 64-bit address and size cells, IOMMU bindings and execution environment–related properties required on newer platforms. Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260514-knp_qce-v2-1-890e3372eef8@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19phy: ti: tusb1210: Move long delayed work on system_dfl_long_wqMarco Crivellari
Currently the code enqueue work items using {queue|mod}_delayed_work(), using system_long_wq. This workqueue should be used when long works are expected and it is a per-cpu workqueue. The function(s) end up calling __queue_delayed_work(), which set a global timer that could fire anywhere, enqueuing the work where the timer fired. Unbound works could benefit from scheduler task placement, to optimize performance and power consumption. Long work shouldn't stick to a single CPU. Recently, a new unbound workqueue specific for long running work has been added:     c116737e972e ("workqueue: Add system_dfl_long_wq for long unbound works") Since the workqueue work doesn't rely on per-cpu variables, there is no obvious reason that justify the use of a per-cpu workqueue. So change system_long_wq with system_dfl_long_wq so that the work may benefit from scheduler task placement. Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://patch.msgid.link/20260507131439.264906-1-marco.crivellari@suse.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19Merge tag 'v7.1-rc4-ksmbd-server-fixes' of git://git.samba.org/ksmbdLinus Torvalds
Pull smb server fixes from Steve French: - Fix two null pointer dereferences and a memory leak * tag 'v7.1-rc4-ksmbd-server-fixes' of git://git.samba.org/ksmbd: ksmbd: fix null pointer dereference in compare_guid_key() ksmbd: fix null pointer dereference in proc_show_files() ksmbd: fix SID memory leak in set_posix_acl_entries_dacl() on overflow
2026-05-19Merge tag 'ntfs-for-7.1-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/ntfs Pull ntfs fixes from Namjae Jeon: - Check the index depth limit via ntfs_icx_parent_inc(), avoiding context corruption from excessively deep child chains - Switch security descriptor allocation to kzalloc() to avoid leaking uninitialized memory - Prevent an inconsistent state where vol->volume_label becomes NULL on allocation failure - Validate MFT records by verifying that attrs_offset sits within bytes_in_use - Fix an off-by-one boundary comparison, correctly catching the out-of-range MFT record number - Validate the attribute name offset and length bounds prior to AT_UNUSED enumeration - Check for a valid left neighbor before runlist merges to prevent an 8byte out-of-bounds write on crafted volumes - Add the missing record comparison against $MFTMirr during mount - Fix wrong inode lookup when writing extent MFT records - Redirty folio on memory allocation failure in ntfs_write_mft_block() - Capture and propagate $MFTMirr sync errors during writeback - Ensure MFT mirror and synchronous writes wait for I/O completion - Fix buffer overflow/heap over-read in ntfs_bdev_write() when cluster size is smaller than PAGE_SIZE - Fix use-after-free in ntfs_inode_sync_filename() when parent index inode is evicted while still holding its mrec_lock - Update resident attribute length validation to match $AttrDef - Fix refcount underflow and UAF of the global upcase table - Fix two smatch warnings * tag 'ntfs-for-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/ntfs: ntfs: restore $MFT mirror contents check ntfs: fix empty_buf and ra lifetime bugs in ntfs_empty_logfile() ntfs: validate attribute name bounds before returning it ntfs: fix MFT bitmap scan 2^32 boundary check ntfs: validate MFT attrs_offset against bytes_in_use ntfs: fix missing kstrdup() error check in ntfs_write_volume_label() ntfs: avoid leaking uninitialised bytes in new security descriptors ntfs: fix out-of-bounds write in ntfs_index_walk_down() ntfs: fix out-of-bounds write in ntfs_rl_collapse_range() merge path ntfs: fix variable dereferenced before check ni in ntfs_attr_open() ntfs: fix default_upcase refcount underflow and UAF on fs_context teardown ntfs: match ntfs_resident_attr_min_value_length with $AttrDef ntfs: avoid use-after-free of index inode in ntfs_inode_sync_filename() ntfs: fix copy length in ntfs_bdev_write() for non-page-aligned start ntfs: wait for sync mft writes to complete ntfs: capture mft mirror sync errors in ntfs_write_mft_block() ntfs: redirty folio when ntfs_write_mft_block() runs out of memory ntfs: use base mft_no when looking up base inode for extent record ntfs: fix variable dereferenced before check ni and attr in ntfs_attrlist_entry_add()
2026-05-19Merge tag 'kbuild-fixes-7.1-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux Pull Kbuild fixes from Nicolas Schier: - modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry() Defensively replace unbound sprintf() calls in file2alias to prevent silent stack overflows and detect alias name overflows with proper error message. - kbuild: pacman-pkg: make "rc" releases adhere to pacman versioning scheme Enable smooth upgrades from "rc" releases w/ pacman packages. * tag 'kbuild-fixes-7.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux: kbuild: pacman-pkg: make "rc" releases adhere to pacman versioning scheme modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
2026-05-19pps: bump PPS device countVadim Fedorenko
Modern systems may have more than 16 PPS sources and current hard-coded limit breaks registration of some devices. Let's bump the limit to 256 in hope it will be enough in foreseen future. Signed-off-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Acked-by: Rodolfo Giometti <giometti@enneenne.com> Link: https://patch.msgid.link/20260515135028.2021318-1-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-19drm/amdgpu: fix handling in amdgpu_userq_createChristian König
Well mostly the same issues the other code had as well: 1. Memory allocation while holding the userq_mutex lock is forbidden! 2. Things were created/started/published in the wrong order. 3. The reset lock was taken in the wrong order and seems to be unecessary in the first place. 4. Error messages on invalid input parameters can spam the logs. 5. Error messages on memory allocation failures are usually superflous as well. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Prike Liang <Prike.Liang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 89e50de5654dbe7a137e03d78629542e17ba7202)
2026-05-19smb: client: use data_len for SMB2 READ encrypted folioq copyJeremy Erazo
In handle_read_data() the encrypted/folioq branch (buf_len <= data_offset, reached via receive_encrypted_read for transform PDUs > CIFSMaxBufSize + MAX_HEADER_SIZE) copies the READ payload using buffer_len rather than data_len: rdata->result = cifs_copy_folioq_to_iter(buffer, buffer_len, cur_off, &rdata->subreq.io_iter); ... rdata->got_bytes = buffer_len; buffer_len comes from the SMB3 transform header OriginalMessageSize field (OriginalMessageSize - read_rsp_size); it represents the size of the decrypted message after the SMB2 header. data_len comes from the SMB2 READ response DataLength field; it represents the actual READ payload size and may be smaller than buffer_len when the decrypted message contains padding or other trailing bytes after the READ payload. The existing check `data_len > buffer_len - pad_len` only enforces an upper bound, so a server that emits OriginalMessageSize larger than read_rsp_size + pad_len + data_len passes the check and the kernel copies buffer_len bytes per response, ignoring the server-asserted DataLength. Two observable failures with a crafted server (DataLength=4, buffer_len=20000): - the kernel returns 20000 bytes per sub-request to userspace and sets got_bytes = buffer_len, even though the response claimed only 4 bytes of payload; - on a partial netfs sub-request whose iterator is sized to data_len, the over-large copy_folio_to_iter() short-reads, cifs_copy_folioq_to_iter() returns -EIO via the n != len path, and the entire netfs read collapses to -EIO even though the leading sub-requests succeeded. Use data_len for the copy length and for got_bytes so the kernel honours the server-asserted READ payload size. For well-formed servers (where buffer_len == pad_len + data_len) the change is behaviour-equivalent. Cc: stable@vger.kernel.org Signed-off-by: Jeremy Erazo <mendozayt13@gmail.com> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-05-19drm/radeon/evergreen_cs: Add missing NULL prefix check in surface checkVitaliy Triang3l Kuzmin
'evergreen_surface_check' is called with a NULL warning prefix when handling potentially recoverable issues or just to compute the alignment requirements, and 'evergreen_surface_check' is called again in case of failure (with the correct prefix, as opposed to NULL), therefore, the initial check must not print a warning, because the surface may be accepted successfully after having been corrected, however if it isn't, the final check will print the warning anyway. The surface check functions specific to array modes already implement this behavior, but the 'evergreen_surface_check' function itself doesn't. This is also supposed to fix the "'%s' directive argument is null [-Werror=format-overflow=]" compiler warning. Fixes: 285484e2d55e ("drm/radeon: add support for evergreen/ni tiling informations v11") Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Vitaliy Triang3l Kuzmin <ml@triang3l.ru> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit e20ea411c99f6968af35fd03e9ee21f70d799144)
2026-05-19drm/amdgpu: userq_va_mapped should remain true once doneSunil Khatri
Multiple queues needs these bo_va objects belonging to the same uq_mgr. So once they are mapped lets not unmap them as at any point of time any of the queues might be using it. Also userq_va_mapped should be a boolean than atomic. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 5c02889ea22575c3bcfdf212e65fac316cbc6c6a)
2026-05-19drm/amdgpu: avoid integer overflow in VA range checkCe Sun
The original addition operation in 64-bit unsigned type may encounter overflow situations. To prevent such issues and safely reject invalid inputs, the check_add_overflow() function is used. Signed-off-by: Ce Sun <cesun102@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit cc768f4dd0bb9083c813683eeec44fc23921f771)
2026-05-19drm/amd/ras: Fix UMC error address allocation leakXiang Liu
amdgpu_umc_handle_bad_pages() allocates err_data->err_addr before querying UMC error information. In the direct and firmware query paths, the pointer is reassigned to a fresh allocation before the original buffer is released, so the initial allocation is leaked on each handled event. Free the existing buffer before replacing it in those query paths so the function exit cleanup only owns the active allocation. Signed-off-by: Xiang Liu <xiang.liu@amd.com> Reviewed-by: Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 911b1bdd22c3712a22b60fcc58f7b9f2d07b0803)
2026-05-19drm/amdgpu: unmap all user mappings of framebuffer and doorbell before mode1 ↵Yifan Zhang
reset During Mode 1 reset, the ASIC undergoes a reset cycle and becomes temporarily inaccessible via PCIe. Any attempt to access framebuffer or MMIO registers during this window can result in uncompleted PCIe transactions, leading to NMI panics or system hangs. To prevent this, Unmap all of the applications mappings of the framebuffer and doorbell BARs before mode1 reset. Also prevent new mappings from coming in during the reset process. v2: remove inode in kfd_dev (Christian) v3: correct unmap offset (Felix), remove prevent new mappings part to avoid deadlock (Christian) Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 70cadefcc6160c575b04f763ada34c20e868d577)
2026-05-19drm/amd/display: Validate payload length and link_index in ↵Harry Wentland
dc_process_dmub_aux_transfer_async [Why&How] dc_process_dmub_aux_transfer_async() copies payload->length bytes into a 16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which is a no-op in release builds. If a caller ever passes length > 16 this results in a stack buffer overflow via memcpy. Additionally, link_index is used to dereference dc->links[] without bounds checking against dc->link_count, risking an out-of-bounds access. Replace the ASSERT with a hard runtime check that returns false when payload->length exceeds the destination buffer size, and add a bounds check for link_index before it is used. Assisted-by: GitHub Copilot:Claude claude-4-opus Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881) Cc: stable@vger.kernel.org
2026-05-19drm/amd/display: Validate GPIO pin LUT table size before iteratingHarry Wentland
[Why&How] The GPIO pin table parsers in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() derive an element count from the VBIOS table_header.structuresize field, then iterate over gpio_pin[] entries. However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read. Fix this by calling bios_get_image() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions. Assisted-by: GitHub Copilot:claude-opus-4-6 Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3) Cc: stable@vger.kernel.org
2026-05-19drm/amd/display: Fix integer overflow in bios_get_image()Harry Wentland
[Why&How] The bounds check in bios_get_image() computes 'offset + size' using unsigned 32-bit arithmetic before comparing against bios_size. If a VBIOS image contains a near-UINT32_MAX offset the addition wraps to a small value, the comparison passes, and the function returns a wild pointer past the VBIOS mapping. Additionally, the comparison uses '<' (strict), which incorrectly rejects the valid exact-fit case where offset + size == bios_size. Fix both issues by restructuring the check to avoid the addition entirely: first reject if offset alone exceeds bios_size, then check size against the remaining space (bios_size - offset). This eliminates the overflow and correctly permits exact-fit accesses. Assisted-by: GitHub Copilot:claude-opus-4.6 Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit d40fb392af659c4a02b560319f226842f6ec1a95) Cc: stable@vger.kernel.org
2026-05-19drm/amdkfd: Check bounds for allocate_sdma_queue restore_sdma_idDavid Francis
allocate_sdma_queue has an option where the sdma queue id can be specified (used by CRIU). We weren't bounds-checking that value. Confirm it's less than the maximum number of queues. Signed-off-by: David Francis <David.Francis@amd.com> Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit bfe9a7545b2a7be1c543f1741e16f2d5ec4116ae)
2026-05-19drm/amdgpu: use atomic operation to achieve lockless serializationSunil Khatri
In amdgpu_seq64_alloc there is a possibility that two difference cores from two separate NODES can try to and could get the same free slot. So this fixes that race here using atomic test_and_set clear operations. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 4d50a14d346141e03a7c3905e496d91e048bc30c)
2026-05-19drm/amdkfd: Check bounds on allocate_doorbellDavid Francis
allocated_doorbell has an option to set the doorbell id to a specific value (used by CRIU). This value was not bounds checked. Check to confirm it's less than KFD_MAX_NUM_OF_QUEUES_PER_PROCESS. Signed-off-by: David Francis <David.Francis@amd.com> Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 1f087bb8cf9e8797633da35c85435e557ef74d06)
2026-05-19drm/amdgpu/vce3: Fix VCE 3 firmware size and offsetsTimur Kristóf
The VCPU BO contains the actual FW at an offset, but it was not calculated into the VCPU BO size. Subtract this from the FW size to make sure there is no out of bounds access. This may fix VM faults when using VCE 3. Cc: John Olender <john.olender@gmail.com> Fixes: e98226221467 ("drm/amdgpu: recalculate VCE firmware BO size") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 15c369257bd85f47a514744f960c5a51c867716f)
2026-05-19drm/amdgpu/vce2: Fix VCE 2 firmware size and offsetsTimur Kristóf
The VCPU BO contains the actual FW at an offset, but it was not calculated into the VCPU BO size. Subtract this from the FW size to make sure there is no out of bounds access. Additionally, increase the VCE_V2_0_DATA_SIZE to have extra space after the VCE handles. Also increase the data size used for each VCE handle. The FW needs 23744 bytes, use 24K to be safe. This fixes VM faults when using VCE 2. Cc: John Olender <john.olender@gmail.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/4802 Fixes: e98226221467 ("drm/amdgpu: recalculate VCE firmware BO size") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit a20d21df625548c1738c0745f753c5d6eb823bc3)
2026-05-19drm/amdgpu/vce1: Stop using amdgpu_vce_resumeTimur Kristóf
The VCE1 firmware works slightly differently and is already loaded by vce_v1_0_load_fw(). It doesn't actually need to call amdgpu_vce_resume(). Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 33d8951405e2dd81ac61edebc680e2dfb6b4fc9f)
2026-05-19drm/amdgpu/vce1: Fix VCE 1 firmware size and offsetsTimur Kristóf
The VCPU BO contains the actual FW at an offset, but it was not calculated into the VCPU BO size. Subtract this from the FW size to make sure there is no out of bounds access. Make sure the stack and data offsets are aligned to the 32K TLB size. Check that the FW microcode actually fits in the space that is reserved for it. Fixes: d4a640d4b9f3 ("drm/amdgpu/vce1: Implement VCE1 IP block (v2)") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c16fe59f622a080fc457a57b3e8f14c780699449)
2026-05-19drm/amdgpu/vce1: Don't repeat GTT MGR node allocationTimur Kristóf
Only allocate entries from the GTT manager when the VCE GTT node is not allocated yet. This prevents the possibility of allocating them multiple times, which causes issues during GPU reset and suspend/resume. Fixes: 71aec08f80e7 ("amdgpu/vce: use amdgpu_gtt_mgr_alloc_entries") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8d2a20c1721cb17e22821e1b4ecbb02d475d91c5)
2026-05-19drm/amdgpu/vce1: Check if VRAM address is lower than GART.Timur Kristóf
Previously, I had assumed this was not possible so it was OK to not handle it, but now we got a report from a user who has a board that is configured this way. When the VCPU BO is already located in a low 32-bit address in VRAM (eg. when VRAM is mapped to the low address space), don't do the workaround. Fixes: 71aec08f80e7 ("amdgpu/vce: use amdgpu_gtt_mgr_alloc_entries") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f370ec9b164698a9ca1a7b59bfbea07f70df769d)
2026-05-19drm/amdgpu/vce1: Remove superfluous address checkTimur Kristóf
The same thing is already checked a few lines above. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c1dc555e760dbfc4a4710f7270f525a03d433af8)
2026-05-19drm/amdgpu/vce1: Check that the GPU address is < 128 MiBTimur Kristóf
When ensuring the low 32-bit address, make sure it is less than 128 MiB, otherwise the VCE seems to fail to initialize. This seems to be an undocumented limitation of the firmware validation mechanism. Note that in case of VCE1 the BAR address is zero and we can't change it also due to the firmware validator. When programming the mmVCE_VCPU_CACHE_OFFSETn registers, don't AND them with a mask. This is incorrect because the register mask is actually 0x0fffffff and useless because we already ensure the addresses are below the limit. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit e729ae5f3ac73c861c062080ac8c3d666c972404)
2026-05-19drm/amdgpu: Align amdgpu_gtt_mgr entries to TLB size on Tahiti (v2)Timur Kristóf
The TLB is organized in groups of 8 entries, each one is 4K. On Tahiti, the HW requires these GART entries to be 32K-aligned. This fixes a VCE 1 firmware validation failure that can happen after suspend/resume since we use amdgpu_gtt_mgr for VCE 1. v2: - Change variable declaration order - Add comment about "V bit HW bug" Fixes: 698fa62f56aa ("drm/amdgpu: Add helper to alloc GART entries") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 530411b465ef0b2c0cc18c2e3d7e38422b1117d1)
2026-05-19drm/amdkfd: Fix OOB memory exposure in get_wave_state()Sunday Clement
The get_wave_state() function for v9 trusts cp_hqd_cntl_stack_size and cp_hqd_cntl_stack_offset values read directly from the MQD, which are written by GPU microcode and fully attacker-controlled on the CRIU-restore path (via AMDKFD_IOC_RESTORE_PROCESS with H3). this leads to an unbounded copy_to_user() that can leak adjacent GTT/kernel memory. If offset > size, integer underflow produces a ~4 GiB read length, if size is set to 1 MiB against a 4 KiB allocation, we leak 1 MiB of adjacent kernel memory (other queues' MQDs, ring buffers, KASLR pointers). Fix by clamping both cp_hqd_cntl_stack_size to the actual allocated buffer size (q->ctl_stack_size) and cp_hqd_cntl_stack_offset to the clamped size before performing arithmetic and copy_to_user(). This ensures we never read beyond the allocated kernel BO regardless of attacker-supplied MQD field values. Signed-off-by: Sunday Clement <Sunday.Clement@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 7ef144458f48d5589e36f1b3d83e83db2e5c5ba5)
2026-05-19drm/amd/pm: fix memleak of dpm_policies on smu v15Yang Wang
In smu_v15_0_fini_smc_tables, dpm_policies was not freed or NULLed, causing a memory leak. Add kfree() and NULL assignment to properly release memory and avoid dangling pointers. Fixes: 2beedc3a92b7 ("drm/amd/pm: Add initial support for smu v15_0_8"); Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 014f329074f688b9b49383e8b70e79e9ef99359e)
2026-05-19drm/amdgpu: Fix discovery offset check under VFLijo Lazar
Discovery table may be kept at offset 0 by host driver. Remove the validation check. Fixes: 01bdc7e219c4 ("drm/amdgpu: New interface to get IP discovery binary v3") Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Ellen Pan <yunru.pan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit d3f5bbd007133c64a20e81ef290a93e46c75df40)
2026-05-19drm/amdgpu: remove va cursors for all mappingsSunil Khatri
va_cursor struct needs to be cleaned even if the mapping has been removed already. Also simplify it by make it a void function as return value check isn't needed as its called during tear down. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 4d35a45c9b4c1ac5b6e3219f83c3db706b675fa2)
2026-05-19drm/amdgpu: reject non-user addresses early in GEM_USERPTR ioctlAmir Shetaia
amdgpu_gem_userptr_ioctl() currently accepts any value of args->addr and only discovers an out-of-range pointer much later, inside amdgpu_gem_object_create() and the HMM mirror registration path. Userspace can drive that path with kernel-side virtual addresses; the get_user_pages() layer rejects them, but only after the driver has already allocated a GEM object and started wiring up notifier state that then has to be torn down on failure. Add an access_ok() guard at the top of the ioctl, right after the existing page-alignment check and before flag validation, so any address that does not lie within the calling task's user address range is rejected with -EFAULT before any allocation occurs. No legitimate ROCm/HSA userspace passes kernel-mode pointers through this interface, so this is defense-in-depth rather than a behaviour change for valid callers; -EFAULT matches the convention already used by other uaccess-style rejections in the kernel. Also add an explicit #include <linux/uaccess.h>; access_ok() is otherwise only available transitively through other headers in this translation unit. Signed-off-by: Amir Shetaia <Amir.Shetaia@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 7a076df36397d780d7e4fb595287b4980451a7f5)
2026-05-19drm/amdgpu/vpe: Force collaborate sync after TRAPAlan Liu
VPE1 could possibly hang and fail to power off at the end of commands in collaboration mode. This workaround adds a COLLAB_SYNC after TRAP to force instances synchronized to avoid VPE1 fail to power off. Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alan liu <haoping.liu@amd.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5171 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit a8b749c5c5afb7e5daa2bfb95d958fb3c6b8f055) Cc: stable@vger.kernel.org
2026-05-19drm/amdgpu/userq: update the vm task info during signal ioctlSunil Khatri
Pagefaults does not have process information correctly populated as vm->task is not set during vm_init but should be updated while real submission. So setting that up during signal_ioctl to get the correct submission process details. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit a9b14d88b4d83e21ab965f23d1fb7b07b87e0517)
2026-05-19drm/amdgpu/userq: cancel reset work while tear down in progressSunil Khatri
While tear down of a userq_mgr is happening when all the queues are free we should cancel any reset work if pending before exiting. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 160164609f71f774c4f661227a9b7a370a86b112)
2026-05-19drm/amdgpu: rework userq reset work handlingChristian König
It is illegal to schedule reset work from another reset work! Fix this by scheduling the userq reset work directly on the work queue of the reset domain. Not fully tested, I leave that to the IGT test cases. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit fd9200ccefab94f27877d1943761d6b0ccbd89c8)
2026-05-19drm/amdgpu/userq: pin mqd and fw object bo to avoid evictionSunil Khatri
mqd and fw objects are queue core objects which should remain valid and never be unmapped and evicted for user queues to work properly. During eviction if these buffers are evicted the hw continue to use the invalid addresses and caused page faults and system hung. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit a3bbf32a336939a1d21b9561f8e53333b684b7ef)
2026-05-19drm/amdgpu/userq: use drm_exec in amdgpu_userq_fence_read_wptrSunil Khatri
To access the bo from vm mapping first lock the root bo and then the object bo of the mapping to make sure both locks are taken safely. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 3aab50410653fe7eb35eb6f9c2b27e3549ab09e6)
2026-05-19firmware: imx: sm-misc: Make scmi_imx_misc_ctrl_nb variable staticKrzysztof Kozlowski
File-scope 'scmi_imx_misc_ctrl_nb' is not used outside of this unit, so make it static to silence sparse warning: sm-misc.c:19:23: warning: symbol 'scmi_imx_misc_ctrl_nb' was not declared. Should it be static? Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19drm/amd/display: Add KUnit test for ISM functionsAlex Hung
Add KUnit tests for three static functions in amdgpu_dm_ism.c: dm_ism_next_state, dm_ism_get_sso_delay, and dm_ism_get_idle_allow_delay. The 32 test cases cover the full FSM transition table, SSO delay calculation with various timings, and hysteresis-based idle allow delay including circular buffer wraparound and old history cutoff logic. Conditionally remove static linkage and export the three functions under CONFIG_DRM_AMD_DC_KUNIT_TEST so the test module can call them. Assisted-by: Copilot:Claude-Opus-4.6 Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-19drm/amd/display: Add KUnit test for replayAlex Hung
Add KUnit tests for amdgpu_dm_link_supports_replay() which validates panel replay capability based on link DPCD caps, freesync state, and VSDB info. Nine test cases cover the positive path and each individual failure condition. Export the function under CONFIG_DRM_AMD_DC_KUNIT_TEST and add the amdgpu include path to the tests Makefile so that amdgpu_dm.h can resolve amdgpu_mode.h types under UML. Assisted-by: Copilot:Claude-Opus-4.6 Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-19drm/amd/display: Add KUnit test for PSR functionAlex Hung
Add KUnit tests for amdgpu_dm_psr_fill_caps() which validates PSR capability population from DPCD data. Export amdgpu_dm_psr_fill_caps() conditionally when CONFIG_DRM_AMD_DC_KUNIT_TEST is enabled, following the existing pattern used by CRC and HDCP test files. The test covers PSR version mapping, RFB setup time calculation, link training flag, DPCD field passthrough, rate control caps, and power optimization flags. Assisted-by: Copilot:Claude-Opus-4.6 Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-19drm/amd/display: Add KUnit test for color helpersAlex Hung
Add KUnit tests for six pure-logic functions in amdgpu_dm_color.c: amdgpu_dm_fixpt_from_s3132, __is_lut_linear, __drm_ctm_to_dc_matrix, __drm_ctm_3x4_to_dc_matrix, amdgpu_tf_to_dc_tf, and amdgpu_colorop_tf_to_dc_tf. Expose these static functions under CONFIG_DRM_AMD_DC_KUNIT_TEST and add a new amdgpu_dm_color.h header with the KUnit-only prototypes. The test file re-declares the dc and amdgpu transfer function enums locally to avoid pulling in the full DC/amdgpu include chain that fails under UML. 26 test cases cover signed-magnitude to two's complement conversion, LUT linearity detection, CTM-to-DC matrix conversion, and transfer function enum mapping. Assisted-by: Copilot:Claude-Opus-4.6 Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-05-19drm/amd/display: Add KUnit test for colorop TF bitmasksAlex Hung
Add KUnit tests that verify the three supported transfer function bitmask constants exported by amdgpu_dm_colorop.c: amdgpu_dm_supported_degam_tfs, amdgpu_dm_supported_shaper_tfs, and amdgpu_dm_supported_blnd_tfs. Each bitmask is tested for presence of each expected curve flag and absence of any unexpected bits. A cross-check confirms that degam and blnd bitmasks are identical. amdgpu_dm_initialize_default_pipeline() is not tested because it needs a fully initialised drm_plane backed by an amdgpu_device with DC color caps. Assisted-by: Copilot:Claude-Opus-4.6 Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>