summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-17drm/amd: Create a device link between APU display and XHCI devicesMario Limonciello
Some AMD APU multi-function devices expose an integrated USB xHCI controller. In some circumstances (such as larger VRAM), the PM core can resume can fail when the xHCI controller is resuming in parallel with the GPU/display function. On affected systems, the xHCI controller can complete pci_pm_resume and start resuming USB devices while the GPU is still in its much longer resume path. This race condition leads to USB device resume failures followed by: xhci_hcd ...: xHCI host not responding to stop endpoint command xhci_hcd ...: HC died; cleaning up Create a device link from any xHCI controller sharing the same PCIe root port as the APU display function. The link uses DL_FLAG_STATELESS and DL_FLAG_PM_RUNTIME to ensure the GPU completes its resume before the xHCI controller begins resuming USB devices. This device link is done specifically in amdgpu so that if the platform firmware has been modified such that this issue doesn't happen the version can be detected and the workaround skipped. Suggested-by: Aaron Ma <aaron.ma@canonical.com> Reported-by: mrh@frame.work Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221073 Acked-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Tested-by: Alexander F <superveridical@gmail.com> Tested-by: Francis DB <francisdb@gmail.com> Link: https://patch.msgid.link/20260713195313.1739762-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 07c93d7eeb0d990bc1b8e3b1eafa464bc9feee97) Cc: stable@vger.kernel.org
2026-07-17drm/amd/display: wire DCN42B mcache programming callbackPengpeng Hou
DCN42B enables DML2 and DML21 by default and defines dcn42b_prepare_mcache_programming(), but the resource function table only wires the callback when CONFIG_DRM_AMD_DC_DML21 is defined. There is no in-tree Kconfig symbol named DRM_AMD_DC_DML21, so the preprocessor always removes the callback entry. Sibling DCN42 and DCN401 resource tables wire their prepare_mcache_programming callbacks unconditionally, and the core DC code already checks whether the callback pointer is present before calling it. Remove the stale guard so DCN42B exposes the callback relation that its source and DML21 build world already provide. This is an RFC patch draft from static conditional callback legality auditing. It needs AMD display maintainer review before submission as a final fix. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Reviewed-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 85453fb4ff726e1ddb9984ee83dca260903c5353)
2026-07-17drm/amd/display: set new_stream to NULL after releaseWenTao Liang
In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. Fixes: 9b690ef3c704 ("drm/amd/display: Avoid full modeset when not required") Signed-off-by: WenTao Liang <vulab@iscas.ac.cn> Reviewed-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28) Cc: stable@vger.kernel.org
2026-07-17drm/amd/display: Force PWM backlight on Lenovo Legion 5 15ARH05Alessandro Rinaldi
The Lenovo Legion 5 15ARH05 (Renoir) ships a BOE 0x08DF eDP panel that advertises AUX/DPCD backlight control, so amdgpu's automatic detection (amdgpu_backlight == -1) selects AUX. On this panel the AUX backlight path has no effect: brightness writes are accepted but the panel level never changes, the display is stuck at a fixed brightness and max_brightness is reported as a bogus 511000. As a result neither the desktop brightness slider nor the brightness hotkeys do anything. Forcing PWM backlight (amdgpu.backlight=0) restores working control: max_brightness becomes 65535 and the level tracks writes. This has long been applied by users as a manual kernel-parameter workaround. Extend the generic panel backlight quirk with a force_pwm flag, add an entry for the Legion 5 15ARH05 / BOE 0x08DF panel, and have amdgpu disable AUX backlight (use PWM) when the quirk matches and the user lets the driver auto-select the backlight type. Signed-off-by: Alessandro Rinaldi <ale@alerinaldi.it> Tested-by: Alessandro Rinaldi <ale@alerinaldi.it> Reviewed-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 81b39f43e7e53589491e2eef6bad5389626b4b9c) Cc: stable@vger.kernel.org
2026-07-17drm/amdkfd: free MQD managers on DQM init failuresGuangshuo Li
The change referenced by the Fixes tag releases the HIQ SDMA MQD trunk buffer when device_queue_manager_init() fails after it has been allocated. However, the same failure path can also be reached after init_mqd_managers() has succeeded. At that point dqm->mqd_mgrs[] contains per-type MQD manager objects owned by the device queue manager. The normal teardown path frees those objects from uninitialize(), but the initialization error path only frees dqm itself. Free the MQD managers from the initialization error path as well. This is safe for earlier failures because dqm is zeroed when allocated and init_mqd_managers() clears the entries it rolls back internally. Fixes: b7cccc8286bb ("drm/amdkfd: fix a memory leak in device_queue_manager_init()") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 1fff2e07b6670bc5b8f7344a8708c136259cb176) Cc: stable@vger.kernel.org
2026-07-17drm/amdgpu/ttm: Consider concurrent VM flushes for buffer entitiesTimur Kristóf
Allow using multiple SDMA schedulers only on GPUs where we are allowed to do concurrent VM flushes. This consideration is necessary because all GART windows are mapped in VMID 0 (the kernel VMID) so each buffer entity would flush VMID 0 concurrently. Practically this means that we can't use multiple SDMA engines for TTM on GFX6-8 and Navi 1x. Fixes: 01c836788b37 ("drm/amdgpu: pass all the sdma scheds to amdgpu_mman") Fixes: e4029f7a9474 ("drm/amdgpu: only use working sdma schedulers for ttm") Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> 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 a8171229bc836607fbc225d323ebc4d14489cfbb)
2026-07-17drm/amd/pm/smu7: Fix AC/DC switch notificationTimur Kristóf
There were two mistakes in the previous implementation: The check for AutomaticDCTransition should be inverted. We recently learned that the kernel should send PPSMC_MSG_RunningOnAC when the flag is set, and not the other way around. The clocks also need to be recomputed, because the code in the smu7_apply_state_adjust_rules() function selects different limits on AC and DC. Fixes: 96da0d86614e ("drm/amd/pm/smu7: Notify SMU7 of DC->AC switch") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 516f8fc30a1b56af03f39e93c18707d13419fb1f) Cc: stable@vger.kernel.org
2026-07-17drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle RidgeMario Limonciello
AMD Ryzen Pinnacle Ridge (Zen+, family 0x17 model 0x08) CPUs have PCI controllers that don't support PCIe dynamic speed switching, causing system freezes during GPU initialization when enabled. Disable dynamic speed switching when this CPU is detected. Assisted-by: Claude:sonnet Fixes: 466a7d115326 ("drm/amd: Use the first non-dGPU PCI device for BW limits") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5436 Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Link: https://patch.msgid.link/20260709031520.841611-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 9ceb4e034a327a04155f32f1cd1a5031dfa5fe02) Cc: stable@vger.kernel.org
2026-07-17drm/amdgpu: always emit the job vm fenceAlex Deucher
We need the fence to reemit the gds switch or spm update after a queue reset. Fixes: a17ef941212b ("drm/amdgpu: rework ring reset backup and reemit v9") Cc: timur.kristof@gmail.com Cc: christian.koenig@amd.com Reviewed-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 bc639a9eadc75822f7f15a4315c198a4b5513bd2) Cc: stable@vger.kernel.org
2026-07-17drm/amd/pm/si: Fix AC/DC switch notificationTimur Kristóf
There were two mistakes in the previous implementation: The check for ATOM_PP_PLATFORM_CAP_HARDWAREDC should be inverted. We recently learned that the kernel should send PPSMC_MSG_RunningOnAC when the flag is set, and not the other way around. The clocks also need to be recomputed, because the code in the si_apply_state_adjust_rules() function selects different limits on AC and DC. Fixes: 2d071f6457af ("drm/amd/pm/si: Notify the SMC when switching to AC") Tested-by: Jeremy Klarenbeek <jeremy.klarenbeek99@gmail.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 358dd0a9ce66d898fa934887385327547d599d88) Cc: stable@vger.kernel.org
2026-07-17drm/amd/pm/si: Don't schedule thermal work when queue isn't initializedTimur Kristóf
When DPM is turned off with the amdgpu.dpm=0 module parameter, the thermal work queue isn't initialized so we shouldn't schedule any work on it. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit bd018d36171a695952c6d391471c279c9e05c8b2)
2026-07-17drm/amd/display: dce100: skip non-DP stream encoders for DP MSTAndriy Korud
On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch Signed-off-by: Andriy Korud <a.korud@gmail.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5162 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8) Cc: stable@vger.kernel.org
2026-07-17drm/amd/display: Set native cursor mode for disabled CRTCsTimur Kristóf
Always set native cursor mode when the CRTC is disabled, to make sure it doesn't cause atomic commits to fail when they are trying to disable the CRTC. Fixes: 41af6215cdbc ("drm/amd/display: Reject cursor plane on DCE when scaled differently than primary") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5432 Cc: Leo Li <sunpeng.li@amd.com> Cc: Michel Dänzer <michel.daenzer@mailbox.org> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 2f79f0130f828cf26fe2dcf45291821616af7b47) Cc: stable@vger.kernel.org
2026-07-17drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)Timur Kristóf
The old radeon driver has a documented workaround in ci_dpm.c which claims that Bonaire 0x6658 with old memory controller firmware is unstable with MCLK DPM, so as a precaution I disabled MCLK DPM on this ASIC in amdgpu. Note that the old MC firmware is not actually used with amdgpu, but in theory it's possible that the VBIOS sets up the ASIC with an old MC firmware that is already running when amdgpu initializes (in which case amdgpu doesn't load its own firmware). What I expected to happen is that the GPU would simply use its maximum memory clock, and indeed this is what seemed to happen according to amdgpu_pm_info which reads the current MCLK value from the SMU. However, some users reported a huge perf regression and upon a closer look it seems that the GPU seems to not actually use the highest MCLK value, despite the SMU reporting that it does. Let's not disable MCLK DPM on Bonaire 0x6658 (R7 260X). Keep MCLK DPM disabled on R9 M380 in the 2015 iMac because that still hangs if we enable it. Fixes: 9851f29cb06c ("drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit d34acad064ee7d82bd18f5d87592c422d4d323ac) Cc: stable@vger.kernel.org
2026-07-17drm/amd/display: fix __udivdi3 link erroryanglinlin
When compiling the AMDGPU display driver for 32-bit architectures, the linker reports undefined reference to `__udivdi3` in functions get_dp_dto_frequency_100hz() and dcn401_get_dp_dto_frequency_100hz(). This is because the code uses 64-bit division (/) on 32-bit systems, which GCC cannot handle directly and instead tries to call the missing __udivdi3 helper function. Replace the raw division with div_u64(), the kernel's standard 64-bit division helper, to avoid the link error. Signed-off-by: Linlin Yang <yanglinlin@kylinos.cn> Reported-by: k2ci <kernel-bot@kylinos.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 0421fc6ab3a8514e99156ff3c2cee13ee9af3fa7) Cc: stable@vger.kernel.org
2026-07-17drm/amdgpu: Reserve space for IB contents in devcoredumpsTimur Kristóf
Currently the contents of IBs are abruptly cut off and don't show the full contents. This patch makes sure to reserve space for those contents too so they may be printed. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 4e2c0821509fed754e8c31d5053d152fbb3484a5) Cc: stable@vger.kernel.org
2026-07-17drm/amdgpu: Print vmid, pasid and more task info in devcoredumpTimur Kristóf
These are in the dmesg logs but are missing from devcoredumps. 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 fed7aa36d79802c3e02acd05aeae8b0a877e47c2) Cc: stable@vger.kernel.org
2026-07-17drm/amdgpu: Release VFCT ACPI table referenceMario Limonciello
amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260708193518.702584-3-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4) Cc: stable@vger.kernel.org
2026-07-17drm/amdgpu: Fix VFCT bus number matching with soft filterMario Limonciello
On systems where PCI bus renumbering occurs (e.g. pci=realloc, resource conflicts), the runtime bus number may differ from the BIOS POST bus number recorded in the VFCT table. This causes amdgpu_acpi_vfct_bios() to fail finding the VBIOS even though the correct device entry exists. Introduce amdgpu_acpi_vfct_match() which treats the bus number as a soft filter: vendor/device/function identity is the hard requirement, while exact bus match is the preferred path. When bus numbers disagree but device identity matches, accept the VFCT entry and log a dev_notice for diagnostics. Reported-by: Oz Tiram <oz@shift-computing.de> Closes: https://lore.kernel.org/amd-gfx/20260621173211.28443-1-oz@shift-computing.de/ Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260708193518.702584-2-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 11c141672045ffc0187aa604f2c0f597bc334fb2) Cc: stable@vger.kernel.org
2026-07-17drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reservedZhu Lingshan
amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. Signed-off-by: Zhu Lingshan <lingshan.zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf) Cc: stable@vger.kernel.org
2026-07-17drm/amdgpu/userq: fix indefinite fence wait during GPU resetJesse Zhang
pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. Fixes: 290f46cf5726 ("drm/amdgpu: Implement user queue reset functionality") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0) Cc: stable@vger.kernel.org
2026-07-17drm/amd/display: fix dcn42b det allocation orderDmytro Laktyushkin
set_pipe_unlock_order needs to be set to true for the pipes to be unlocked in correct order to avoid det overallocation Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 183bbded999a70c5996e8f399fa8790568d71112)
2026-07-17drm/amd/display: fix dcn42 det allocation orderDmytro Laktyushkin
set_pipe_unlock_order needs to be set to true for the pipes to be unlocked in correct order to avoid det overallocation Reviewed-by: Taimur Hassan <syed.hassan@amd.com> Signed-off-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 198663d035cc439eb48844a2da66f6ae1b0de303)
2026-07-17drm/amd/display: Fix backlight max_brightness to match exported rangeMario Limonciello
[Why] FWTS autobrightness fails on eDP panels because actual_brightness can read higher than the advertised max_brightness (e.g. 63576 vs 62451). The conversion helpers expose the firmware PWM range to userspace as [0..max]. But max_brightness is advertised as (max - min), which is smaller. So reading the level can return a value above max_brightness. This regressed in commit 4b61b8a39051 ("drm/amd/display: Add debugging message for brightness caps"), which changed max_brightness to (max - min) and undid commit 8dbd72cb7900 ("drm/amd/display: Export full brightness range to userspace"). [How] Advertise max_brightness as max, and scale the initial AC/DC brightness against max too. Update the KUnit expectations to match. Fixes: 4b61b8a39051 ("drm/amd/display: Add debugging message for brightness caps") Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit bd9e2b5b0473c75abc0f4134dfe79ecbfb16610d) Cc: stable@vger.kernel.org
2026-07-17drm/amd/display: Fix 8K Mode Not Parsed by EDIDFangzhi Zuo
[why] The 8K120/8K240 timings live in DisplayID extension blocks 2 and 3 of this EDID. The EDID is a 4-block (512-byte) HDMI 2.1 EDID that uses HF-EEODB. drm core reads and parses this correctly, but amdgpu rebuilds its own copy. Only 2 of 4 blocks were copied into sink->dc_edid, that leads to drm_edid_connector_add_modes() never sees blocks 2 and 3. [how] Directly populate edid_blob_ptr with a blob whose length is the full, and HF-EEODB-aware size. Reviewed-by: Sun peng (Leo) Li <sunpeng.li@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 11a90eaf5c808ba800249dda0d481c35d0888589)
2026-07-17drm/amd/display: Add dp_skip_rbr flag for NUTMEGTimur Kristóf
No functional changes. Just clean up a conceptual mismatch. Based on feedback on the NUTMEG code in DC, the preferred_link_setting is meant to force the DP link to a specific setting, meaning both the link rate and lane count should be locked to an exact value. What NUTMEG needs is a lower bound on the link rate, which is not the same concept. Implement this as a HW workaround flag instead. Suggested-by: Wenjing Liu <wenjing.liu@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 871ceb853841bcaa4e6cec3723b16c4887a760be) Cc: stable@vger.kernel.org
2026-07-17drm/amd/display: Fix preferred link rate for NUTMEGTimur Kristóf
When there is a preferred link rate setting, it needs to be applied to both the current and initial link rate. This was regressed by a "coding style" fix, which caused the current link rate to not respect the preferred value. This commit restores the functionality of NUTMEG, the DP bridge encoder found on old APUs such as Kaveri. Fixes: a62346043a89 ("drm/amd/display: Fix coding style issue") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5465 Cc: Chuanyu Tseng <Chuanyu.Tseng@amd.com> Reviewed-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit e78b0a367f8690b682029d90e75308dc84ed51de) Cc: stable@vger.kernel.org
2026-07-17drm/amdkfd: fix 32-bit overflow in CWSR total size calculationYongqiang Sun
total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). Signed-off-by: Yongqiang Sun <Yongqiang.Sun@amd.com> Reviewed-by: Philip Yang <philip.yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608) Cc: stable@vger.kernel.org
2026-07-17drm/amd/display: Fix DCN42B null registers & register masksMatthew Stewart
[why] DCN42B is missing some register masks, which are causing errors in dmesg. [how] Make DCN42B reuse the DCN42 register lists, and add the missing defines manually. Fixes: 64142f9d51af ("drm/amd/display: Fix DCN42 null registers & register masks") Reviewed-by: Ovidiu (Ovi) Bunea <ovidiu.bunea@amd.com> Signed-off-by: Matthew Stewart <Matthew.Stewart2@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit b7d69145907cdefcbd39a70a31eefd30919af9f1)
2026-07-17drm/amdgpu/discovery: Fix device family for DCN42Roman Li
GC 11.7.0 and 11.7.1 should map to AMDGPU_FAMILY_GC_11_5_4 for DCN42. Fixes: cf591e67c095 ("drm/amdgpu: add support for GC IP version 11.7.0") Fixes: a928d8d81ec5 ("drm/amdgpu: add support for GC IP version 11.7.1") Signed-off-by: Roman Li <Roman.Li@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f8ee6447e7ec1d75d6663c817e45566dd01f440b)
2026-07-17Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf 7.2-rc4Kumar Kartikeya Dwivedi
Cross-merge BPF and other fixes after downstream PR. Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-18Merge tag 'drm-intel-fixes-2026-07-17' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes Couple of display fixes (NV12 for bigjoiner and Watermark clear on plane disable) along with couple of GT selftests fixes. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/alp3ks0K1ZsxUC05@intel.com
2026-07-17drm/nouveau: Omit a redundant pm_runtime_mark_last_busy() call in ↵Markus Elfring
nouveau_pmops_runtime_idle() The device's last busy timestamp was set in a wrapper function since the commit 08071e64cb642ae19ebd6ffeb13b4f3d130b5860 ("PM: runtime: Mark last busy stamp in pm_runtime_autosuspend()"). Thus delete a pm_runtime_mark_last_busy() call before a pm_runtime_autosuspend() call. The source code was transformed by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/e3631a8e-b4a4-4e14-822d-2199f1576cc9@web.de
2026-07-18Merge tag 'drm-xe-fixes-2026-07-17' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOCK (Himal) - Hold a dma-buf reference for imported BOs (Nitin) - Fix writable override for CRI (Alexander) - Fix VF CCS attach/detach race with in-flight BO moves (Matthew Brost) - Fix WOPCM size for LNL+ (Daniele) - Reset current_op in xe_pt_update_ops_init (Zongyao Bai) - Keep scheduler timeline name alive (Arvind) - Hold device ref until queue teardown completes (Arvind) - Disable display in admin only PF mode (Satyanarayana) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/aln1tRUXZJ_qzD65@fedora
2026-07-18Merge tag 'drm-misc-fixes-2026-07-17' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v7.2-rc4: - Fix UAF in host1x, amdxdna. - Handle invalid firmware log in ivpu. - Fix error handling in panthor. - Handle NULL pages and backup handles in ttm_pool_backup() correctly. - Reject more invalid amdxdna command submissions. - Improve unmap and error handling on gpusvm. - Fix virtio deadlock and invalid gem detach. - Fix wrong read in ivpu. - Always synchronize for CPU in begin_cpu_udmabuf. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/7f10281e-88f5-4be5-8b42-367e7ce7c547@linux.intel.com
2026-07-17Merge branch 'fix-leftover-issues-of-the-unify-bpf_call_arg_meta-patchset'Eduard Zingerman
Amery Hung says: ==================== Fix leftover issues of the unify bpf_call_arg_meta patchset Hi, This patchset fixes preexisting issues flagged by Sashiko when reviewing the patchset unifying bpf_call_arg_meta [0]. [0] https://lore.kernel.org/bpf/20260715064047.1793790-1-ameryhung@gmail.com/ ==================== Link: https://patch.msgid.link/20260715172127.2416388-1-ameryhung@gmail.com Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-07-17bpf: Zero kfunc arg meta before error paths can read itAmery Hung
check_kfunc_call() reads meta.func_name when bpf_fetch_kfunc_arg_meta() returns -EACCES, but that error can come from fetch_kfunc_meta() (e.g. fd_array_get_btf() rejecting BTF binding for a signed program) before meta is memset(), leaving it uninitialized and risking a garbage deref in verbose(). Move the memset() to the start of bpf_fetch_kfunc_arg_meta() so meta is zeroed on every error return. The intended "not allowed" -EACCES path still sets func_name first, so its message is unchanged. Signed-off-by: Amery Hung <ameryhung@gmail.com> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://patch.msgid.link/20260715172127.2416388-3-ameryhung@gmail.com Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-07-17bpf: Disable raw mode for bloom filter map_peekAmery Hung
For a bloom filter, the value argument of bpf_map_peek_elem() is always an input. Therefore, the verifier should not allow passing uninitialized stack memory to it to avoid information leak. bpf_map_peek_elem() tags its value argument ARG_PTR_TO_MAP_VALUE | MEM_UNINIT, telling the verifier the callee fills the buffer. This holds for queue/stack maps, but not for a bloom filter, which reads the buffer as an input to test set membership and never writes it. As a result, a program can pass an uninitialized stack buffer to bpf_map_peek_elem() on a bloom filter. The verifier accepts it and marks the buffer initialized on return, letting the program read back leftover kernel stack memory. Bloom maps require CAP_BPF to create, so this is a CAP_BPF-gated stack infoleak that bypasses the boundary CAP_BPF is meant to enforce (arbitrary kernel reads are gated behind CAP_PERFMON). Signed-off-by: Amery Hung <ameryhung@gmail.com> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://patch.msgid.link/20260715172127.2416388-2-ameryhung@gmail.com Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-07-17Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfLinus Torvalds
Pull bpf fixes from Kumar Kartikeya Dwivedi: - Fix a UAF in socket clone early bailout paths (Matt Bobrowski) - Reject unhashed UDP sockets on sockmap update to prevent refcount leaks (Michal Luczaj) - Account for receive queue data in FIONREAD on sockmap sockets without a verdict program (Mattia Meleleo) - Reject negative constant offsets for verifier buffer pointers (Sun Jian) - Fix for tracing of kfuncs with implicit arguments (Ihor Solodrai) * tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: selftests/bpf: Cover tracing implicit kfunc args bpf: Fix tracing of kfuncs with implicit args selftests/bpf: Cover negative buffer pointer offsets bpf: Reject negative const offsets for buffer pointers selftests/bpf: Test FIONREAD on a sockmap socket without a verdict program bpf, sockmap: Account for receive queue in FIONREAD without a verdict program selftests/bpf: Fail unbound UDP on sockmap update selftests/bpf: Adapt sockmap update error handling bpf, sockmap: Reject unhashed UDP sockets on sockmap update selftests/bpf: Ensure UDP sockets are bound bpf: Fix UAF in sock clone early bailouts
2026-07-17dm vdo: don't read repair field in loop conditionMatthew Sakai
Respell the vio launch loop to use the existing vio_count value. The repair completion is not guaranteed to persist after all of the metadata_vios are launched. This can not currently cause problems due to the way vio callbacks are handled, but it is technically not safe to access those fields. Signed-off-by: Matthew Sakai <msakai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-07-17dm-pcache: only hand out initialized cache segmentsBryam Vargas
get_cache_segment() scans the segment map up to cache->n_segs, the physical device segment count, but cache_segs_init() only initializes the first cache_info->n_segs segments. A crafted image with cache_info->n_segs smaller than the device count leaves the remaining pcache_cache_segment structs zeroed (segment.data == NULL), and the allocator can hand one to cache_kset_close(), which writes through the returned segment's data pointer with no NULL check. Bound the allocator's search to cache_info->n_segs so only initialized segments are ever returned. A conforming cache sets n_segs equal to the device segment count, so this rejects nothing legitimate. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-07-17dm-pcache: validate the persisted dirty_tail chain at loadBryam Vargas
The writeback worker follows the persisted dirty_tail chain, which is decoded from the cache device independently of the key_tail chain that cache_replay() walks and bounds. A crafted image, whose on-media fields are authenticated only by a crc32c with a fixed seed, can aim dirty_tail at a chain of last ksets that never terminates, so cache_writeback_fn() re-arms itself with no delay forever. Walk the dirty_tail chain once at load with the same hop cap cache_replay() uses and fail the table load with -EIO if it does not reach an end within n_segs hops. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-07-17dm-pcache: validate on-media seg_num against the cache device sizeBryam Vargas
seg_num is read from the crc32c-only superblock, so whoever supplies the cache device on a table load (CAP_SYS_ADMIN) controls it. It sizes cache->segments[] and is the value every later on-media segment id is bounded against, yet it is never checked against the device. Because cache_dev->mapping is the direct map of the pmem, CACHE_DEV_SEGMENT() for a segment id past the device resolves to ordinary kernel memory beyond the mapping; a new-cache init reaching such an id has cache_seg_init() -> cache_dev_zero_range() memset() 12 KiB over that memory -- an out-of-bounds write into the kernel heap at table load. A zero seg_num makes the segment allocations ZERO_SIZE_PTR. Reject a seg_num that is zero, larger than the device can hold, or larger than PCACHE_CACHE_SEGS_MAX before it is used. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-07-17dm-pcache: clamp the tail kset read to the segment data regionBryam Vargas
The tail-kset read in cache_replay(), the writeback worker and the GC worker bounds its length by PCACHE_SEG_SIZE - seg_off, the raw segment size rather than the data region. A tail near the segment end reads past the segment data into the following control area. Clamp the read to cache_seg_remain(), the data region. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-07-17dm-pcache: bound the logical key offset from persistent memoryBryam Vargas
cache_key_decode() takes a key's logical off from the cache device and later indexes req_key_tree->subtrees[] by it in get_subtree(). An off past the device forms a subtree pointer outside the array, which rb_insert() writes through during replay. Reject a key of zero length, or whose off+len (computed in 64 bits) exceeds the device size, before it is used. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-07-17dm-pcache: detect a cycle in the last-kset chain during replayBryam Vargas
cache_replay() follows the on-media last-kset chain by next_cache_seg_id with no cond_resched(). A forged chain that points back into a segment it has already visited makes the replay loop follow it forever. Cap the last-kset hops at cache->n_segs; a valid chain visits each segment at most once. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-07-17dm-pcache: reject a kset that overruns its segmentBryam Vargas
cache_replay(), the writeback worker and the GC worker read a kset of get_kset_onmedia_size() bytes and advance the position by it. A forged key_num makes that size exceed the segment's remaining space, so the advance walks past the segment and trips the cache_pos_advance() BUG_ON. Reject a kset whose on-media size exceeds cache_seg_remain() before use. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-07-17dm-pcache: bound the persisted tail-position offsetBryam Vargas
cache_pos_decode() takes the persisted key_tail and dirty_tail seg_off from the cache device and addresses within the segment with it. A seg_off at or past the segment data_size, controllable by whoever supplies the device (CAP_SYS_ADMIN), reads past the segment data. Reject a decoded seg_off that is not below the segment data_size. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-07-17dm-pcache: validate kset key_num and intra-segment boundsBryam Vargas
Two more fields decoded from the cache device go unbounded. The kset key_num drives cache_kset_crc() and the replay loop in cache_replay(), the writeback worker and the GC worker, but only the magic and a fixed-seed CRC are checked first, so a non-last kset whose key_num exceeds the PCACHE_KSET_KEYS_MAX buffer reads past its end before the CRC compare. A key's intra-segment offset and length in cache_key_decode() are taken verbatim, so a key running past its segment is replayed into the cache tree and the data CRC check and every later read hit then copy adjacent persistent memory into the caller's bio -- an out-of-bounds read that leaks to user space. Both fields are controlled by whoever supplies the cache device (CAP_SYS_ADMIN); the CRC seed is public. Add kset_onmedia_valid() to bound key_num before any kset read, and reject a key whose offset plus length, computed in 64 bits, exceeds the segment data_size. Valid metadata is unaffected. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-07-17dm-pcache: validate geometry fields from on-disk cache_infoBryam Vargas
cache_segs_init() iterates cache_info->n_segs times indexing cache->segments[], which is sized to the cache device geometry, and get_seg_id() takes each segment id from the on-media cache_info and the per-segment next_seg link. Both come from cache device metadata that is only CRC-protected with a fixed public seed, so whoever supplies the cache device on a table load (CAP_SYS_ADMIN) controls them: an oversized n_segs or an out-of-range id drives an out-of-bounds access of cache->segments[] and a wild CACHE_DEV_SEGMENT() pointer into the device mapping -- an out-of-bounds read and write from on-disk data. Reject an n_segs that exceeds the device segment count and a segment id that is out of range before either is used. Valid metadata is unaffected. Fixes: 1d57628ff95b ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-08 17:28:36 +0000