summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-05-19arm64: dts: imx8ulp-evk: Correct Type-C int GPIO flagsKrzysztof Kozlowski
IRQ_TYPE_xxx flags are not correct in the context of GPIO flags. These are simple defines so they could be used in DTS but they will not have the same meaning: IRQ_TYPE_EDGE_FALLING = 2 = GPIO_SINGLE_ENDED. Correct the Type-C int-gpios to use proper flags, assuming the author of the code wanted similar logical behavior: IRQ_TYPE_EDGE_FALLING => GPIO_ACTIVE_LOW Fixes: c4b4593ecb0b ("arm64: dts: imx8ulp-evk: enable usb nodes and add ptn5150 nodes") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-05-19firmware: arm_ffa: Honor partition info descriptor sizeJamie Nguyen
FFA_PARTITION_INFO_GET_REGS reports the size of each partition information descriptor in x2[63:48]. However, __ffa_partition_info_get_regs() walks the returned register payload with a hardcoded 24-byte stride (regs += 3), even though the size is already read into buf_sz. That works for the FF-A v1.1/v1.2 24-byte descriptor layout, where each descriptor consumes three registers. Newer FF-A revisions can extend the descriptor while keeping the existing fields at the front. For example, a 48-byte descriptor consumes six registers, so advancing by only three registers desynchronises the parser and can make it read subsequent entries from the middle of a descriptor. Use the advertised descriptor size to derive the register stride. Validate that the size is register-aligned, large enough for the fields parsed by the driver, and that the requested number of descriptors fits in the returned x3..x17 register window. The driver still copies only the fields it understands, but now skips over any trailing descriptor fields correctly. Fixes: ba85c644ac8d ("firmware: arm_ffa: Add support for FFA_PARTITION_INFO_GET_REGS") Suggested-by: Sudeep Holla <sudeep.holla@kernel.org> Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Link: https://patch.msgid.link/20260518203116.42624-1-jamien@nvidia.com (sudeep.holla: Minor rewordng of the commit message and subject) Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-19bio-integrity-fs: pass data iter to bio_integrity_verify()Caleb Sander Mateos
bio_integrity_verify() expects the passed struct bvec_iter to be an iterator over bio data, not integrity. So construct a separate data bvec_iter without the bio_integrity_bytes() conversion and pass it to bio_integrity_verify() instead of bip_iter. Fixes: 0bde8a12b554 ("block: add fs_bio_integrity helpers") Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Anuj Gupta <anuj20.g@samsung.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260513182924.1753582-1-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-05-19ipmi: Use named initializers for struct i2c_device_idUwe Kleine-König (The Capable Hub)
While being less compact, using named initializers allows to more easily see which members of the structs are assigned which value without having to lookup the declaration of the struct. And it's also more robust against changes to the struct definition. This patch doesn't modify the compiled arrays, only their representation in source form benefits. The former was confirmed with x86 and arm64 builds. While touching these arrays, unify usage of whitespace in the list terminator. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Message-ID: <20260519150156.1590826-2-u.kleine-koenig@baylibre.com> Signed-off-by: Corey Minyard <corey@minyard.net>
2026-05-19drm/i915/bw: Extract get_display_bw_params()Gustavo Sousa
Just like it is done for the platform-specific bandwidth parameters, use a separate function named get_display_bw_params() to return the display IP-specific parameters. This simplifies intel_bw_init_hw() by having just one call for each of the *_get_bw_info() functions. v2: - Prefer to call get_display_bw_params() only once in intel_bw_init_hw() instead of having multiple calls in each of the affected *_get_bw_info() functions. (Jani) v3: - Call get_display_bw_params() only after the check on HAS_DISPLAY(display). (Jani) - Return &gen11_bw_params only if display version is 11. (Matt) v4: - Like done with get_soc_bw_params(), drop drm_WARN() when no display IP is matched. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-5-918528006549@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19drm/i915/bw: Rename struct intel_sa_info to intel_display_bw_paramsGustavo Sousa
To align with struct intel_platform_bw_params, rename struct intel_sa_info to intel_display_bw_params. Also add comments to contrast their purposes. v2: - Use gen11 and gen12 as prefixes for ICL's and TGL's display-specific parameters variables. (Matt) - Prefer to use "display" instead of "disp" in variable names. (Jani) - Drop the redundant "disp" from the variable names. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-4-918528006549@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19drm/i915/bw: Deduplicate intel_sa_info instancesGustavo Sousa
Now that intel_sa_info contains bandwidth parameters specific to the display IP, we can drop many duplicates and reuse from previous releases. Let's do that and also simplify intel_bw_init_hw() while at it. v2: - Drop rkl_sa_info and reuse icl_sa_info. (Matt) - Add comment explaining RKL's display's peculiarity on using ICL's parameters. (Matt) - Don't rename xelpdp_sa_info to mtl_sa_info. Renaming of instances to use IP names will be done in upcoming changes. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-3-918528006549@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19drm/i915/bw: Extract platform-specific parametersGustavo Sousa
We got confirmation from the hardware team that the bandwidth parameters deprogbwlimit and derating are platform-specific and not tied to the display IP. As such, let's make sure that we use platform checks for those. The rest of the members of struct intel_sa_info are tied to the display IP and we will deal with them as a follow-up. v2: - Use good old if-ladder instead of weird-looking pattern "assign ret, check platform, then return ret". (Jani, Matt) - Have a single call site for get_platform_bw_params() and pass the result as parameter to the *_get_bw_info() functions. (Jani) - Avoid using "plat" as abbreviation for "platform". (Jani) - s/_plat_bw_params/_bw_params/, since all of the instances are prefixed with platform names. (Jani) - s/struct intel_platform_bw_params/struct intel_soc_bw_params/. (Matt) - Do not return a default value; prefer to return NULL and intentionally cause a NULL pointer dereference if a platform is missing. (Gustavo) v3: - Call get_soc_bw_params() only after the check on HAS_DISPLAY(display). (Jani) - Combine if-ladder branches for adl_s_bw_params into a single one. (Matt) - Flatten if-ladder by checking for WCL before PTL (as opposed to checking for WCL inside the brace for PTL). (Matt) - Bail out of intel_bw_init_hw() if display version is below 11. (Gustavo) v4: - Drop drm_WARN() when no platform was matched to avoid special-casing DG2 and any other platform that doesn't use SoC-specific parameters. (Jani) - Pass dram_info to get_soc_bw_params() to keep a single call to intel_dram_info(). (Jani) - Don't use 2 separate if-ladders (one for client and another for discrete platforms) and keep a single one for simplicity. (Gustavo) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-2-918528006549@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19drm/i915/bw: Don't call intel_dram_info() too earlyGustavo Sousa
If we end-up bailing early from intel_bw_init_hw() due to !HAS_DISPLAY(display), the call to intel_dram_info() to initialize dram_info will be meaningless. Move the call to be done after that check. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-1-918528006549@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-19dmaengine: Move MODULE_DEVICE_TABLE next to the table itselfKrzysztof Kozlowski
By convention MODULE_DEVICE_TABLE() immediately follows the ID table it exports, because this is easier to read and verify. It also makes more sense since #ifdef for ACPI or OF could hide both of them. Most of the drivers already have this correctly placed, so adjust the missing ones. No functional impact. Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260514060525.9253-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19dt-bindings: dma: qcom,gpi: Document the Eliza GPI DMA engineAbel Vesa
Document the GPI DMA engine found on the Eliza SoC. It is fully compatible with the GPI DMA engine found on SM6350, thus using qcom,sm6350-gpi-dma as fallback compatible. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com> Link: https://patch.msgid.link/20260515-eliza-gpi-dma-v2-1-1255b43d5ca9@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19dmaengine: mmp_pdma: add SpacemiT K3 supportGuodong Xu
SpacemiT K3 reuses most of the PDMA IP design found on K1, with one difference being the extended DRCMR base address. Add "spacemit,k3-pdma" compatible string and define a new mmp_pdma_ops for K3 PDMA. Signed-off-by: Guodong Xu <guodong@riscstar.com> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Link: https://patch.msgid.link/20260518-k3-pdma-v6-3-67fdf319a8f8@linux.spacemit.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19dmaengine: mmp_pdma: refactor DRCMR access with helper functionGuodong Xu
Refactor the DRCMR macro into a helper function mmp_pdma_get_drcmr() to support variable extended DRCMR base addresses across different PDMA implementations, such as SpacemiT K3. Signed-off-by: Guodong Xu <guodong@riscstar.com> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Link: https://patch.msgid.link/20260518-k3-pdma-v6-2-67fdf319a8f8@linux.spacemit.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
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)
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-08 01:15:48 +0000