summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2026-02-02drm/panel: boe-th101mb31ig002: Remove use of deprecated mipi_dsi_dcs_nop()Caio Ishikawa
Replace calls to deprecated mipi_dsi_dcs_nop() with mipi_dsi_dcs_nop_multi(). No intended functional changes. Signed-off-by: Caio Ishikawa <caio.ishikawa@proton.me> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260124124959.196051-3-caio.ishikawa@proton.me
2026-02-02drm/i915/display: fix the pixel normalization handling for xe3p_lpdVinod Govindapillai
Pixel normalizer is enabled with normalization factor as 1.0 for FP16 formats in order to support FBC for those formats in xe3p_lpd. Previously pixel normalizer gets disabled during the plane disable routine. But there could be plane format settings without explicitly calling the plane disable in-between and we could endup keeping the pixel normalizer enabled for formats which we don't require that. This is causing crc mismatches in yuv formats and FIFO underruns in planar formats like NV12. Fix this by updating the pixel normalizer configuration based on the pixel formats explicitly during the plane settings arm calls itself - enable it for FP16 and disable it for other formats in HDR capable planes. v2: avoid redundant pixel normalization setting updates v3: moved the normalization factor definition to intel_fbc.c and some updates to comments v4: simplified the pixel normalizer setting handling Fixes: 5298eea7ed20 ("drm/i915/xe3p_lpd: use pixel normalizer for fp16 formats for FBC") Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260130095919.107805-1-vinod.govindapillai@intel.com (cherry picked from commit c0dc68f4e2aa7eddb9ec6d95931f9576d8fe7334) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-02-02drm/vc4: Replace IDR with XArray for perfmon trackingMaíra Canal
The IDR interface is deprecated and the XArray API is the recommended replacement. Replace the per-file IDR used to track perfmons with an XArray. This allows us to remove the external mutex that protects the IDR. While at it, introduce the vc4_perfmon_delete() helper to consolidate the perfmon cleanup logic used by both vc4_perfmon_close_file() and vc4_perfmon_destroy_ioctl(). Also, remove the redundant assignment of vc4file->dev to itself in vc4_perfmon_open_file(). Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patch.msgid.link/20260127115822.64401-2-mcanal@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-02-02drm/v3d: Replace IDR with XArray for perfmon trackingMaíra Canal
The IDR interface is deprecated and the XArray API is the recommended replacement. Replace the per-file IDR used to track perfmons with an XArray. This allows us to remove the external mutex that protects the IDR. While here, introduce the v3d_perfmon_delete() helper to consolidate the perfmon cleanup logic used by both v3d_perfmon_close_file() and v3d_perfmon_destroy_ioctl(). Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patch.msgid.link/20260127115822.64401-1-mcanal@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-02-02drm/xe: Apply WA_16028005424 to MediaBalasubramani Vivekanandan
Apply WA_16028005424 to following IPs: Xe2_LPM, Xe2_HPM, Xe3_LPM, Xe3p_LPM While doing this move the same WA defined for Xe3_LPG under the comment for Xe3_LPG. It was wrongly placed under Xe3_LPM. Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260128062911.1456539-2-balasubramani.vivekanandan@intel.com
2026-02-02drm/i915/display: fix the pixel normalization handling for xe3p_lpdVinod Govindapillai
Pixel normalizer is enabled with normalization factor as 1.0 for FP16 formats in order to support FBC for those formats in xe3p_lpd. Previously pixel normalizer gets disabled during the plane disable routine. But there could be plane format settings without explicitly calling the plane disable in-between and we could endup keeping the pixel normalizer enabled for formats which we don't require that. This is causing crc mismatches in yuv formats and FIFO underruns in planar formats like NV12. Fix this by updating the pixel normalizer configuration based on the pixel formats explicitly during the plane settings arm calls itself - enable it for FP16 and disable it for other formats in HDR capable planes. v2: avoid redundant pixel normalization setting updates v3: moved the normalization factor definition to intel_fbc.c and some updates to comments v4: simplified the pixel normalizer setting handling Fixes: 5298eea7ed20 ("drm/i915/xe3p_lpd: use pixel normalizer for fp16 formats for FBC") Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260130095919.107805-1-vinod.govindapillai@intel.com
2026-02-02Revert "drm/gma500: use drm_crtc_vblank_crtc()"Jani Nikula
This reverts commit d930ffa5d6e8867a290db9c6aad1c62731aeb2c3. According to Thomas, commit d930ffa5d6e8 ("drm/gma500: use drm_crtc_vblank_crtc()") breaks the driver with a NULL-ptr oops on startup. This is because the IRQ initialization in gma_irq_install() now uses CRTCs that are only allocated later in psb_modeset_init(). Stack trace is below. Revert. Go back to the drawing board. [ 65.831766] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000021: 0000 [#1] SMP KASAN NOPTI [ 65.832114] KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] [ 65.832232] CPU: 1 UID: 0 PID: 296 Comm: (udev-worker) Tainted: G E 6.19.0-rc6-1-default+ #4622 PREEMPT(voluntary) [ 65.832376] Tainted: [E]=UNSIGNED_MODULE [ 65.832448] Hardware name: /DN2800MT, BIOS MTCDT10N.86A.0164.2012.1213.1024 12/13/2012 [ 65.832543] RIP: 0010:drm_crtc_vblank_crtc+0x24/0xd0 [ 65.832652] Code: 90 90 90 90 90 90 0f 1f 44 00 00 48 89 f8 48 81 c7 18 01 00 00 48 83 ec 10 48 ba 00 00 00 00 00 fc ff df 48 89 f9 48 c1 e9 03 <0f> b6 14 11 84 d2 74 05 80 fa 03 7e 58 48 89 c6 8b 90 18 01 00 00 [ 65.832820] RSP: 0018:ffff88800c8f7688 EFLAGS: 00010006 [ 65.832919] RAX: fffffffffffffff0 RBX: ffff88800fff4928 RCX: 0000000000000021 [ 65.833011] RDX: dffffc0000000000 RSI: ffffc90000978130 RDI: 0000000000000108 [ 65.833107] RBP: ffffed1001ffea03 R08: 0000000000000000 R09: ffffed100191eec7 [ 65.833199] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8880014480c8 [ 65.833289] R13: dffffc0000000000 R14: fffffffffffffff0 R15: ffff88800fff4000 [ 65.833380] FS: 00007fe53d4d5d80(0000) GS:ffff888148dd8000(0000) knlGS:0000000000000000 [ 65.833488] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 65.833575] CR2: 00007fac707420b8 CR3: 000000000ebd1000 CR4: 00000000000006f0 [ 65.833668] Call Trace: [ 65.833735] <TASK> [ 65.833808] gma_irq_preinstall+0x190/0x3e0 [gma500_gfx] [ 65.834054] gma_irq_install+0xb2/0x240 [gma500_gfx] [ 65.834282] psb_driver_load+0x7b2/0x1090 [gma500_gfx] [ 65.834516] ? __pfx_psb_driver_load+0x10/0x10 [gma500_gfx] [ 65.834726] ? ksize+0x1d/0x40 [ 65.834817] ? drmm_add_final_kfree+0x3b/0xb0 [ 65.834935] ? __pfx_psb_pci_probe+0x10/0x10 [gma500_gfx] [ 65.835164] psb_pci_probe+0xc8/0x150 [gma500_gfx] [ 65.835384] local_pci_probe+0xd5/0x190 [ 65.835492] pci_call_probe+0x167/0x4b0 [ 65.835594] ? __pfx_pci_call_probe+0x10/0x10 [ 65.835693] ? local_clock+0x11/0x30 [ 65.835808] ? __pfx___driver_attach+0x10/0x10 [ 65.835915] ? do_raw_spin_unlock+0x55/0x230 [ 65.836014] ? pci_match_device+0x303/0x790 [ 65.836124] ? pci_match_device+0x386/0x790 [ 65.836226] ? __pfx_pci_assign_irq+0x10/0x10 [ 65.836320] ? kernfs_create_link+0x16a/0x230 [ 65.836418] ? do_raw_spin_unlock+0x55/0x230 [ 65.836526] ? __pfx___driver_attach+0x10/0x10 [ 65.836626] pci_device_probe+0x175/0x2c0 [ 65.836735] call_driver_probe+0x64/0x1e0 [ 65.836842] really_probe+0x194/0x740 [ 65.836951] ? __pfx___driver_attach+0x10/0x10 [ 65.837053] __driver_probe_device+0x18c/0x3a0 [ 65.837163] ? __pfx___driver_attach+0x10/0x10 [ 65.837262] driver_probe_device+0x4a/0x120 [ 65.837369] __driver_attach+0x19c/0x550 [ 65.837474] ? __pfx___driver_attach+0x10/0x10 [ 65.837575] bus_for_each_dev+0xe6/0x150 [ 65.837669] ? local_clock+0x11/0x30 [ 65.837770] ? __pfx_bus_for_each_dev+0x10/0x10 [ 65.837891] bus_add_driver+0x2af/0x4f0 [ 65.838000] ? __pfx_psb_init+0x10/0x10 [gma500_gfx] [ 65.838236] driver_register+0x19f/0x3a0 [ 65.838342] ? rcu_is_watching+0x11/0xb0 [ 65.838446] do_one_initcall+0xb5/0x3a0 [ 65.838546] ? __pfx_do_one_initcall+0x10/0x10 [ 65.838644] ? __kasan_slab_alloc+0x2c/0x70 [ 65.838741] ? rcu_is_watching+0x11/0xb0 [ 65.838837] ? __kmalloc_cache_noprof+0x3e8/0x6e0 [ 65.838937] ? klp_module_coming+0x1a0/0x2e0 [ 65.839033] ? do_init_module+0x85/0x7f0 [ 65.839126] ? kasan_unpoison+0x40/0x70 [ 65.839230] do_init_module+0x26e/0x7f0 [ 65.839341] ? __pfx_do_init_module+0x10/0x10 [ 65.839450] init_module_from_file+0x13f/0x160 [ 65.839549] ? __pfx_init_module_from_file+0x10/0x10 [ 65.839651] ? __lock_acquire+0x578/0xae0 [ 65.839791] ? do_raw_spin_unlock+0x55/0x230 [ 65.839886] ? idempotent_init_module+0x585/0x720 [ 65.839993] idempotent_init_module+0x1ff/0x720 [ 65.840097] ? __pfx_cred_has_capability.isra.0+0x10/0x10 [ 65.840211] ? __pfx_idempotent_init_module+0x10/0x10 Reported-by: Thomas Zimmermann <tzimmermann@suse.de> Closes: https://lore.kernel.org/r/5aec1964-072c-4335-8f37-35e6efb4910e@suse.de Fixes: d930ffa5d6e8 ("drm/gma500: use drm_crtc_vblank_crtc()") Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patch.msgid.link/20260130151319.31264-1-jani.nikula@intel.com
2026-02-02drm/i915/psr: Use TRANS_PUSH to trigger frame change eventJouni Högander
Now we have everything in place for triggering PSR "frame change" event using TRANS_PUSH: use TRANS_PUSH for LunarLake and onwards. v4: - Added call to intel_vrr_psr_frame_change_enable call - added setting LNL_TRANS_PUSH_PSR_PR_EN into intel_vrr_send_push v3: use HAS_PSR_FRAME_CHANGE macro v2: use AND instead of OR in intel_psr_use_trans_push Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-12-jouni.hogander@intel.com
2026-02-02drm/i915/display: Add HAS_PSR_TRANS_PUSH_FRAME_CHANGE macroJouni Högander
Add a macro indicating that the platform supports triggering a Frame Change event for the PSR HW using the TRANS PUSH mechanism. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-11-jouni.hogander@intel.com
2026-02-02drm/i915/psr: Do PSR exit on frontbuffer flush on LunarLake and onwardsJouni Högander
We need to use intel_psr_exit in frontbuffer flush on LunarLake and onwards if we want to move using trans push mechanism to trigger Frame Change event. Keep PSR1 and PSR2 HW tracking as it is for older platforms as this was seen causing problems there. v2: typo fixed Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-10-jouni.hogander@intel.com
2026-02-02drm/i915/psr: Wait for idle only after possible send pushJouni Högander
We are planning to move using trans push mechanism to trigger the Frame Change event. In that case we can't wait PSR to idle before send push happens. Due to this move wait for idle to be done after possible send push is done. This should be ok for Frame Change event triggered by register write as well. Wait for idle is needed only for corner case where PSR is transitioning into DEEP_SLEEP when Frame Change event is triggered. It just has to be before wait for vblank. Otherwise we may have vblank before PSR enters DEEP_SLEEP and still using old frame buffers for first frame after wake up. v2: some typos fixed Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-9-jouni.hogander@intel.com
2026-02-02drm/i915/display: Wait for vblank in case of PSR is using trans pushJouni Högander
In case PSR uses trans push as a "frame change" event and we need to wait vblank after triggering PSR "frame change" event. Otherwise we may miss selective updates. DSB skips all waits while PSR is active. Check push send is skipped as well because trans push send bit is not reset by the HW if VRR is not enabled -> we may start configuring new selective update while previous is not complete. Avoid this by waiting for vblank after sending trans push. v2: some typos fixed Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-8-jouni.hogander@intel.com
2026-02-02drm/i915/dsb: Set DSB_SKIP_WAITS_EN chicken bit for LunarLake and onwardsJouni Högander
On LunarLake we are using TRANS_PUSH mechanism to trigger "Frame Change" event. This way we have more control on when PSR HW is woken up. I.e. not every display register write is triggering sending update. This allows us setting DSB_SKIP_WAITS_EN chicken bit as well. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-7-jouni.hogander@intel.com
2026-02-02drm/i915/vrr: Prepare to Use TRANS_PUSH mechanism for PSR frame changeJouni Högander
On Lunarlake and onward it is possible to generate PSR Frame Change event using TRANS_PUSH mechanism: Ensure push is performed on flip if needed by PSR. Don't use intel_psr_trigger_frame_change_event if PSR uses trans push as Frame Change event: When not using trans push to generate Frame Change event plane/pipe register writes are triggering the event. This is causing problems when transiting to PSR active/idle and the event is coming in. To tackle this we are waiting PSR to idle and using intel_psr_trigger_frame_change_event to ensure PSR exit. If the Frame change event is triggered after everything is configured (on trans push) we don't need to worry about all this. Ensure possible intel_vrr_tg_disable call is not overwriting LNL_TRANS_PUSH_PSR_PR_EN. v8: - split adding intel_vrr_psr_frame_change_enable as a separate change - update commit message v7: - HAS_PSR_FRAME_CHANGE macro moved to separate patch and renamed as HAS_PSR_TRANS_PUSH_FRAME_CHANGE - use intel_psr_use_trans_push instead of HAS_PSR_FRAME_CHANGE in intel_psr_trigger_frame_change - moved calling intel_vrr_psr_frame_change_enable away from this patch v6: - add HAS_PSR_FRAME_CHANGE macro - use TRANS_PUSH in instead of TRAN_VRR_CTL v5: use intel_psr_use_trans_push for intel_vrr_psr_frame_change_enable v4: - use rmw when enabling/disabling transcoder - set TRANS_PUSH_EN conditionally in intel_vrr_send_push - do not call intel_vrr_send_push from intel_psr_trigger_frame_change - do not enable using TRANS_PUSH mechanism for PSR "Frame Change" v3: - use rmw when enabling/disabling - keep LNL_TRANS_PUSH_PSR_PR_EN set always on LunarLake and onwards v2: use intel_vrr_trans_push_enabled_set_clear instead of rmw Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-6-jouni.hogander@intel.com
2026-02-02drm/i915/vrr: Add helper for PSR to enable Frame Change event on trans pushJouni Högander
Add new helper to enable PSR Frame Change event generation using trans push mechanism. This helper is to be used by PSR code on PSR enable. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-5-jouni.hogander@intel.com
2026-02-02drm/i915/vrr: Add helper for parsing value to be written into TRANS_PUSHJouni Högander
On Lunarlake and onwards it is possible to generate PSR "frame change" event using TRANS_PUSH mechanism. As a preparation add new helper to parse value to be written into TRANS_PUSH register. Setting LNL_TRANS_PUSH_PSR_PR_EN is done in upcoming change. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-4-jouni.hogander@intel.com
2026-02-02drm/i915/psr: Add intel_psr_use_trans_push to query if TRANS_PUSH is usedJouni Högander
This is a preparation to start using trans push as a PSR "Frame Change" event. It adds intel_psr_use_trans_push placeholder which return false for now until we have everything in place. v2: - modify commit message - add TODO Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-3-jouni.hogander@intel.com
2026-02-02drm/i915/psr: Add TRANS_PUSH register bit definition for PSRJouni Högander
Add TRANS_PUSH register bit LNL_TRANS_PUSH_PSR_PR_EN definition for PSR usage. v2: add bspec reference Bspec: 69984 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-2-jouni.hogander@intel.com
2026-02-02Merge tag 'exynos-drm-next-for-v6.20' of ↵Dave Airlie
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next Fix three regressions . Fix a regression where vidi_connection_ioctl() used the wrong device to look up the vidi context. It stores the vidi device in exynos_drm_private and uses it in ioctl(), preventing invalid pointer access and related bugs. . Fix a security regression where vidi_connection_ioctl() directly dereferenced a user pointer for EDID data. It copies EDID from user space with copy_from_user() into kernel memory before use, preventing arbitrary kernel memory access. . Fix a concurrency regression where vidi_context members related to EDID memory were accessed without locking. It protects alloc/free and state updates with ctx->lock, preventing race conditions and use-after-free bugs. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Inki Dae <inki.dae@samsung.com> Link: https://patch.msgid.link/20260201143939.27074-1-inki.dae@samsung.com
2026-02-01Revert "drm/nouveau/disp: Set drm_mode_config_funcs.atomic_(check|commit)"John Ogness
This reverts commit 604826acb3f53c6648a7ee99a3914ead680ab7fb. Apparently there is more to supporting atomic modesetting than providing atomic_(check|commit) callbacks. Before this revert: WARNING: [] drivers/gpu/drm/drm_plane.c:389 at .__drm_universal_plane_init+0x13c/0x794 [drm], CPU#1: modprobe/1790 BUG: Kernel NULL pointer dereference on read at 0x00000000 .drm_atomic_get_plane_state+0xd4/0x210 [drm] (unreliable) .drm_client_modeset_commit_atomic+0xf8/0x338 [drm] .drm_client_modeset_commit_locked+0x80/0x260 [drm] .drm_client_modeset_commit+0x40/0x7c [drm] .__drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0xfc/0x108 [drm_kms_helper] .drm_fb_helper_set_par+0x8c/0xb8 [drm_kms_helper] .fbcon_init+0x31c/0x618 [...] .__drm_fb_helper_initial_config_and_unlock+0x474/0x7f4 [drm_kms_helper] .drm_fbdev_client_hotplug+0xb0/0x120 [drm_client_lib] .drm_client_register+0x88/0xe4 [drm] .drm_fbdev_client_setup+0x12c/0x19b4 [drm_client_lib] .drm_client_setup+0x15c/0x18c [drm_client_lib] .nouveau_drm_probe+0x19c/0x268 [nouveau] Fixes: 604826acb3f5 ("drm/nouveau/disp: Set drm_mode_config_funcs.atomic_(check|commit)") Reported-by: John Ogness <john.ogness@linutronix.de> Closes: https://lore.kernel.org/lkml/87ldhf1prw.fsf@jogness.linutronix.de Signed-off-by: John Ogness <john.ogness@linutronix.de> Tested-by: Daniel Palmer <daniel@thingy.jp> Link: https://patch.msgid.link/20260130113230.2311221-1-john.ogness@linutronix.de Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-02-02Merge tag 'amd-drm-next-6.20-2026-01-30' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.20-2026-01-30: amdgpu: - Misc cleanups - SMU 13 fixes - SMU 14 fixes - GPUVM fault filter fix - USB4 fixes - DC FP guard fixes - Powergating fix - JPEG ring reset fix - RAS fixes - Xclk fix for soc21 APUs - Fix COND_EXEC handling for GC 11 - UserQ fixes - MQD size alignment fixes - SMU feature interface cleanup - GC 10-12 KGQ init fixes - GC 11-12 KGQ reset fixes amdkfd: - Fix device snapshot reporting - GC 12.1 trap handler fixes - MQD size alignment fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260130183257.28879-1-alexander.deucher@amd.com
2026-02-01drm/exynos: vidi: use ctx->lock to protect struct vidi_context member ↵Jeongjun Park
variables related to memory alloc/free Exynos Virtual Display driver performs memory alloc/free operations without lock protection, which easily causes concurrency problem. For example, use-after-free can occur in race scenario like this: ``` CPU0 CPU1 CPU2 ---- ---- ---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... drm_mode_getconnector() drm_helper_probe_single_connector_modes() vidi_get_modes() if (ctx->raw_edid) // true drm_edid_dup(ctx->raw_edid); if (!drm_edid) // false ... vidi_connection_ioctl() if (vidi->connection) // false drm_edid_free(ctx->raw_edid); // free drm_edid ... drm_edid_alloc(drm_edid->edid) kmemdup(edid); // UAF!! ... ``` To prevent these vulns, at least in vidi_context, member variables related to memory alloc/free should be protected with ctx->lock. Cc: <stable@vger.kernel.org> Signed-off-by: Jeongjun Park <aha310510@gmail.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2026-02-01drm/exynos: vidi: fix to avoid directly dereferencing user pointerJeongjun Park
In vidi_connection_ioctl(), vidi->edid(user pointer) is directly dereferenced in the kernel. This allows arbitrary kernel memory access from the user space, so instead of directly accessing the user pointer in the kernel, we should modify it to copy edid to kernel memory using copy_from_user() and use it. Cc: <stable@vger.kernel.org> Signed-off-by: Jeongjun Park <aha310510@gmail.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2026-02-01drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl()Jeongjun Park
vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to obtain a struct vidi_context pointer. However, drm_dev->dev is the exynos-drm master device, and the driver_data contained therein is not the vidi component device, but a completely different device. This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more. To resolve this issue, we need to store/delete the vidi device pointer in exynos_drm_private->vidi_dev during bind/unbind, and then read this exynos_drm_private->vidi_dev within ioctl() to obtain the correct struct vidi_context pointer. Cc: <stable@vger.kernel.org> Signed-off-by: Jeongjun Park <aha310510@gmail.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2026-01-31kernel.h: drop STACK_MAGIC macroYury Norov
Patch series "Unload linux/kernel.h", v5. kernel.h hosts declarations that can be placed better. This series decouples kernel.h with some explicit and implicit dependencies; also, moves tracing functionality to a new independent header. This patch (of 6): The macro was introduced in 1994, v1.0.4, for stacks protection. Since that, people found better ways to protect stacks, and now the macro is only used by i915 selftests. Move it to a local header and drop from the kernel.h. Link: https://lkml.kernel.org/r/20260116042510.241009-1-ynorov@nvidia.com Link: https://lkml.kernel.org/r/20260116042510.241009-2-ynorov@nvidia.com Signed-off-by: Yury Norov <ynorov@nvidia.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Reviewed-by: Aaron Tomlin <atomlin@atomlin.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Petr Pavlu <petr.pavlu@suse.com> Cc: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-31Merge branch 'mm-hotfixes-stable' into mm-nonmm-stable to pick up changesAndrew Morton
required to merge "kho: use unsigned long for nr_pages".
2026-01-30Merge tag 'rust-fixes-6.19' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust fixes from Miguel Ojeda: "Toolchain and infrastructure: - Trigger rebuilds of the newly added 'proc-macro2' crate (and its dependencies) when the Rust compiler version changes - Fix error in '.rsi' targets (macro expanding single targets) under 'O=' pointing to an external (not subdir) folder - Fix off-by-one line number in 'rustdoc' KUnit tests - Add '-fdiagnostics-show-context' to GCC flags skipped by 'bindgen' - Clean objtool warning by adding one more 'noreturn' function - Clean 'libpin_init_internal.{so,dylib}' in 'mrproper' 'kernel' crate: - Fix build error when using expressions in formatting arguments - Mark 'num::Bounded::__new()' as unsafe and clean documentation accordingly - Always inline functions using 'build_assert' with arguments - Fix 'rusttest' build error providing the right 'isize_atomic_repr' type for the host 'macros' crate: - Fix 'rusttest' build error by ignoring example rust-analyzer: - Remove assertion that was not true for distributions like NixOS - Add missing dependency edges and fix editions for 'quote' and sysroot crates to provide correct IDE support DRM Tyr: - Fix build error by adding missing dependency on 'CONFIG_COMMON_CLK' Plus clean a few typos in docs and comments" * tag 'rust-fixes-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (28 commits) rust: num: bounded: clean __new documentation and comments scripts: generate_rust_analyzer: fix resolution of #[pin_data] macros drm/tyr: depend on `COMMON_CLK` to fix build error rust: sync: atomic: Provide stub for `rusttest` 32-bit hosts kbuild: rust: clean libpin_init_internal in mrproper rust: proc-macro2: rebuild if the version text changes rust: num: bounded: add missing comment for always inlined function rust: sync: refcount: always inline functions using build_assert with arguments rust: bits: always inline functions using build_assert with arguments scripts: generate_rust_analyzer: compile sysroot with correct edition scripts: generate_rust_analyzer: compile quote with correct edition scripts: generate_rust_analyzer: quote: treat `core` and `std` as dependencies scripts: generate_rust_analyzer: syn: treat `std` as a dependency scripts: generate_rust_analyzer: remove sysroot assertion rust: kbuild: give `--config-path` to `rustfmt` in `.rsi` target scripts: generate_rust_analyzer: Add pin_init_internal deps scripts: generate_rust_analyzer: Add pin_init -> compiler_builtins dep scripts: generate_rust_analyzer: Add compiler_builtins -> core dep rust: macros: ignore example with module parameters rust: num: bounded: mark __new as unsafe ...
2026-01-31drm/radeon: Make MSI address limit based on the device DMA limitVivian Wang
The radeon driver restricts the MSI message address for devices older than the BONAIR generation to 32-bit MSI addresses due to the former restrictions of the PCI/MSI code which only allowed either 32-bit or full 64-bit address range. This does not work on platforms which have a MSI doorbell address above the 32-bit boundary but do not support the full 64 bit address range. The PCI/MSI core converted this binary decision to a DMA_BIT_MASK() based decision, which allows to describe the device limitations precisely. Convert the driver to provide the exact DMA address limitations to the PCI/MSI core. That allows devices which do not support the full 64-bit address space to work on platforms which have a MSI doorbell address above the 32-bit limit as long as it is within the hardware's addressable range. [ tglx: Massage changelog ] Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20260129-pci-msi-addr-mask-v4-3-70da998f2750@iscas.ac.cn
2026-01-31PCI/MSI: Convert the boolean no_64bit_msi flag to a DMA address maskVivian Wang
Some PCI devices have PCI_MSI_FLAGS_64BIT in the MSI capability, but implement less than 64 address bits. This breaks on platforms where such a device is assigned an MSI address higher than what's supported. Currently, no_64bit_msi bit is set for these devices, meaning that only 32-bit MSI addresses are allowed for them. However, on some platforms the MSI doorbell address is above the 32-bit limit but within the addressable range of the device. As a first step to enable MSI on those combinations of devices and platforms, convert the boolean no_64bit_msi flag to a DMA mask and fixup the affected usage sites: - no_64bit_msi = 1 -> msi_addr_mask = DMA_BIT_MASK(32) - no_64bit_msi = 0 -> msi_addr_mask = DMA_BIT_MASK(64) - if (no_64bit_msi) -> if (msi_addr_mask < DMA_BIT_MASK(64)) Since no values other than DMA_BIT_MASK(32) and DMA_BIT_MASK(64) are used, this is functionally equivalent. This prepares for changing the binary decision between 32 and 64 bit to a DMA mask based decision which allows to support systems which have a DMA address space less than 64bit but a MSI doorbell address above the 32-bit limit. [ tglx: Massaged changelog ] Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> # ionic Reviewed-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Takashi Iwai <tiwai@suse.de> # sound Link: https://patch.msgid.link/20260129-pci-msi-addr-mask-v4-1-70da998f2750@iscas.ac.cn
2026-01-30drm/xe/pf: Fix typo in function kernel-docMichal Wajdeczko
The function name is missing an underscore, which results in: Warning: ../drivers/gpu/drm/xe/xe_gt_sriov_pf_control.c:1261 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst * xe_gt_sriov_pf_control_trigger restore_vf() - Start ... Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20251217150702.2669-1-michal.wajdeczko@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-01-30drm/panel-edp: Add CMN N116BCL-EAK (C2)Cong Yang
Add support for the CMN N116BCL-EAK (C2) panel, pleace the EDID here for subsequent reference. edid-decode (hex): 00 ff ff ff ff ff ff 00 0d ae 7a 11 00 00 00 00 08 22 01 04 95 1a 0e 78 03 46 a5 9c 5b 53 8b 24 1d 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 e6 1e 56 e2 50 00 3c 30 30 20 a6 00 00 90 10 00 00 1a 00 00 00 fd 00 28 3c 32 32 08 01 0a 20 20 20 20 20 20 00 00 00 fe 00 43 4d 4e 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 4e 31 31 36 42 43 4c 2d 45 41 4b 0a 20 01 80 70 20 79 02 00 25 01 09 fc 34 01 fc 34 01 28 3c 80 81 00 10 72 1a 00 00 03 01 28 3c 00 00 00 00 00 00 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2f 90 Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260130030456.2080748-1-yangcong5@huaqin.corp-partner.google.com
2026-01-30drm/bridge: dw-hdmi-qp: Rework Audio InfoFrame handlerCristian Ciocaltea
Make use of the recently introduced dw_hdmi_qp_write_infoframe() helper to simplify the writing of the Audio InfoFrame packet header and body registers. Additionally, discard the redundant static values identifying the frame version and length. Moreover, since now having dedicated callbacks per InfoFrame type, move the implementation to dw_hdmi_qp_bridge_write_audio_infoframe() and drop dw_hdmi_qp_config_audio_infoframe(). Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260129-dw-hdmi-qp-iframe-v2-5-0157ad05232c@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-01-30drm/bridge: dw-hdmi-qp: Rework DRM InfoFrame handlerCristian Ciocaltea
Make use of the recently introduced dw_hdmi_qp_write_infoframe() helper to simplify the writing of the Dynamic Range and Mastering (DRM) InfoFrame packet header and body registers. Moreover, since now having dedicated callbacks per InfoFrame type, move the implementation to dw_hdmi_qp_bridge_write_hdr_drm_infoframe() and drop dw_hdmi_qp_config_drm_infoframe(). While at it, also discard the unnecessary infoframe size verification, as well as the redundant disabling of the packet transmission (already done by the explicit call to the clear callback). Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260129-dw-hdmi-qp-iframe-v2-4-0157ad05232c@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-01-30drm/bridge: dw-hdmi-qp: Rework AVI InfoFrame handlerCristian Ciocaltea
Make use of the recently introduced dw_hdmi_qp_write_infoframe() helper to simplify the writing of the Auxiliary Video InfoFrame (AVI) packet header and body registers. Moreover, since now having dedicated callbacks per InfoFrame type, move the implementation to dw_hdmi_qp_bridge_write_avi_infoframe() and drop dw_hdmi_qp_config_avi_infoframe(). While at it, also discard the superfluous infoframe size verification. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260129-dw-hdmi-qp-iframe-v2-3-0157ad05232c@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-01-30drm/bridge: dw-hdmi-qp: Provide SPD InfoFrameCristian Ciocaltea
The hardware is capable of sending Source Product Description (SPD) InfoFrames, hence enable the missing support. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260129-dw-hdmi-qp-iframe-v2-2-0157ad05232c@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-01-30drm/bridge: dw-hdmi-qp: Provide HDMI Vendor Specific InfoFrameCristian Ciocaltea
Since commit b626b1a1c9cc ("drm/bridge: refactor HDMI InfoFrame callbacks"), the following warning is generated: [ 13.654149] rockchip-drm display-subsystem: [drm] HDMI VSI not supported Add the missing support for sending HDMI Vendor-Specific Infoframes. Additionally, introduce dw_hdmi_qp_write_{pkt|infoframe}() helpers, as a prerequisite to rework all dw_hdmi_qp_bridge_write_*_infoframe() callbacks and get rid of some boilerplate code. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260129-dw-hdmi-qp-iframe-v2-1-0157ad05232c@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-01-30drm/i915: move intel_gvt_init() level higherMichał Grzelak
Both initialisation and removal of GVT happen at different abstraction levels. Hence caller of i915_driver_hw_probe() has no way of knowing status of intel_gvt_init(). This can lead to an unbalanced number of calls of intel_gvt_init() and intel_gvt_driver_remove() since GVT error path is currently handled in i915_driver_probe(). One such scenario has been seen with i915_driver_hw_probe() fault injection, which caused double entry deletion and list corruption. Move intel_gvt_init() up to i915_driver_probe(). Add out_cleanup_gvt error path for removing gvt. Trigger it only after intel_gvt_init() succeeded. In case intel_gvt_init() failed, theoretically we should follow err_msi error path. That is actually impossible since call to intel_gvt_init() unconditionally returns 0, although it claims to return negative error code on failure. Thus follow standard out_cleanup_hw error path on a hypothetical future intel_gvt_init() failure. Remove err_msi label from i915_driver_hw_probe() since intel_gvt_init() was the only user of it. Changelog: v1->v2 - don't move err_msi error path from i915_driver_hw_probe (Jani) - rewrite commit message Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15481 Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patch.msgid.link/20260129090129.2601661-2-michal.grzelak@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-29Merge tag 'drm-fixes-2026-01-30' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Seems to be a bit quieter this week, mostly xe and amdgpu, with msm and imx fixes and one WARN_ON from user blocked. Nothing of note outstanding either. uapi: - Fix a WARN_ON() when passing an invalid handle to drm_gem_change_handle_ioctl() msm: - GPU: - Fix bogus hwcg register update for a690 xe: - Skip address copy for sync-only execs - Fix a WA - Derive mem_copy cap from graphics version - Fix is_bound() pci_dev lifetime - xe nvm cleanup fixes amdgpu: - SMU 13 fixes - SMU 14 fixes - GPUVM fault filter fix - Powergating fix - HDMI debounce fix - Xclk fix for soc21 APUs - Fix COND_EXEC handling for GC 11 - GC 10-12 KGQ init fixes - GC 11-12 KGQ reset fixes imx/tve: - drop ddc device reference when unloading" * tag 'drm-fixes-2026-01-30' of https://gitlab.freedesktop.org/drm/kernel: (21 commits) drm/xe/nvm: Fix double-free on aux add failure drm/xe/nvm: Manage nvm aux cleanup with devres drm/amdgpu/gfx12: adjust KGQ reset sequence drm/amdgpu/gfx11: adjust KGQ reset sequence drm/amdgpu/gfx12: fix wptr reset in KGQ init drm/amdgpu/gfx11: fix wptr reset in KGQ init drm/amdgpu/gfx10: fix wptr reset in KGQ init drm/xe/configfs: Fix is_bound() pci_dev lifetime drm/amdgpu: Fix cond_exec handling in amdgpu_ib_schedule() drm/amdgpu/soc21: fix xclk for APUs drm/amd/display: Clear HDMI HPD pending work only if it is enabled drm/imx/tve: fix probe device leak drm/amd/pm: fix race in power state check before mutex lock drm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_remove drm/amd/pm: fix smu v14 soft clock frequency setting issue drm/amd/pm: fix smu v13 soft clock frequency setting issue drm/xe: derive mem copy capability from graphics version drm/xe/xelp: Fix Wa_18022495364 drm/xe: Skip address copy for sync-only execs drm: Do not allow userspace to trigger kernel warnings in drm_gem_change_handle_ioctl() ...
2026-01-30Merge tag 'drm-xe-next-fixes-2026-01-29' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next - Reduce LRC timestamp stuck message on VFs to notice (Brost) - Disable GuC Power DCC strategy on PTL (Vinay) - Unregister drm device on probe error (Lin) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/aXuyrtsnlAOmj_OB@intel.com
2026-01-30Merge tag 'drm-misc-next-fixes-2026-01-29' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next Two fixes for NULL pointer dereference in imx8 following the bridge refcounting conversions, and one for the bridge connector following the HDMI audio reworks. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260129-efficient-jerboa-of-ecstasy-822832@houat
2026-01-30Merge tag 'drm-intel-next-fixes-2026-01-29' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next - Prevent u64 underflow in intel_fbc_stolen_end Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/aXsWGWjacEJ03rTs@jlahtine-mobl
2026-01-30Merge tag 'drm-misc-fixes-2026-01-29' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v6.19-rc8: - Fix a WARN_ON() when passing an invalid handle to drm_gem_change_handle_ioctl() - drop ddc device reference when unloading in imx/tve. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/a34d967e-b111-4b29-8c97-af3e77b5d33e@linux.intel.com
2026-01-30Merge tag 'amd-drm-fixes-6.19-2026-01-29' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.19-2026-01-29: amdgpu: - SMU 13 fixes - SMU 14 fixes - GPUVM fault filter fix - Powergating fix - HDMI debounce fix - Xclk fix for soc21 APUs - Fix COND_EXEC handling for GC 11 - GC 10-12 KGQ init fixes - GC 11-12 KGQ reset fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260129212518.22274-1-alexander.deucher@amd.com
2026-01-30Merge tag 'drm-xe-fixes-2026-01-29' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Skip address copy for sync-only execs (Lin) - Fix a WA (Tvrtko) - Derive mem_copy cap from graphics version (Nitin) - Fix is_bound() pci_dev lifetime (Lin) - xe nvm cleanup fixes (Lin) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/aXu_JzBFb9YVFYW1@fedora
2026-01-29drm/xe/nvm: Fix double-free on aux add failureShuicheng Lin
After a successful auxiliary_device_init(), aux_dev->dev.release (xe_nvm_release_dev()) is responsible for the kfree(nvm). When there is failure with auxiliary_device_add(), driver will call auxiliary_device_uninit(), which call put_device(). So that the .release callback will be triggered to free the memory associated with the auxiliary_device. Move the kfree(nvm) into the auxiliary_device_init() failure path and remove the err goto path to fix below error. " [ 13.232905] ================================================================== [ 13.232911] BUG: KASAN: double-free in xe_nvm_init+0x751/0xf10 [xe] [ 13.233112] Free of addr ffff888120635000 by task systemd-udevd/273 [ 13.233120] CPU: 8 UID: 0 PID: 273 Comm: systemd-udevd Not tainted 6.19.0-rc2-lgci-xe-kernel+ #225 PREEMPT(voluntary) ... [ 13.233125] Call Trace: [ 13.233126] <TASK> [ 13.233127] dump_stack_lvl+0x7f/0xc0 [ 13.233132] print_report+0xce/0x610 [ 13.233136] ? kasan_complete_mode_report_info+0x5d/0x1e0 [ 13.233139] ? xe_nvm_init+0x751/0xf10 [xe] ... " v2: drop err goto path. (Alexander) Fixes: 7926ba2143d8 ("drm/xe: defer free of NVM auxiliary container to device release callback") Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Brian Nguyen <brian3.nguyen@intel.com> Cc: Alexander Usyskin <alexander.usyskin@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Suggested-by: Brian Nguyen <brian3.nguyen@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260120183239.2966782-7-shuicheng.lin@intel.com (cherry picked from commit a3187c0c2bbd947ffff97f90d077ac88f9c2a215) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-29drm/xe/nvm: Manage nvm aux cleanup with devresShuicheng Lin
Move nvm teardown to a devm-managed action registered from xe_nvm_init(). This ensures the auxiliary NVM device is deleted on probe failure and device detach without requiring explicit calls from remove paths. As part of this, drop xe_nvm_fini() from xe_device_remove() and from the survivability sysfs teardown, and remove the public xe_nvm_fini() API from the header. This is to fix below warn message when there is probe failure after xe_nvm_init(), then xe_device_probe() is called again: " [ 207.318152] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:01.0/0000:03:00.0/xe.nvm.768' [ 207.318157] CPU: 5 UID: 0 PID: 10261 Comm: modprobe Tainted: G B W 6.19.0-rc2-lgci-xe-kernel+ #223 PREEMPT(voluntary) [ 207.318160] Tainted: [B]=BAD_PAGE, [W]=WARN [ 207.318161] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023 [ 207.318163] Call Trace: [ 207.318163] <TASK> [ 207.318165] dump_stack_lvl+0xa0/0xc0 [ 207.318170] dump_stack+0x10/0x20 [ 207.318171] sysfs_warn_dup+0xd5/0x110 [ 207.318175] sysfs_create_dir_ns+0x1f6/0x280 [ 207.318177] ? __pfx_sysfs_create_dir_ns+0x10/0x10 [ 207.318179] ? lock_acquire+0x1a4/0x2e0 [ 207.318182] ? __kasan_check_read+0x11/0x20 [ 207.318185] ? do_raw_spin_unlock+0x5c/0x240 [ 207.318187] kobject_add_internal+0x28d/0x8e0 [ 207.318189] kobject_add+0x11f/0x1f0 [ 207.318191] ? __pfx_kobject_add+0x10/0x10 [ 207.318193] ? lockdep_init_map_type+0x4b/0x230 [ 207.318195] ? get_device_parent.isra.0+0x43/0x4c0 [ 207.318197] ? kobject_get+0x55/0xf0 [ 207.318199] device_add+0x2d7/0x1500 [ 207.318201] ? __pfx_device_add+0x10/0x10 [ 207.318203] ? lockdep_init_map_type+0x4b/0x230 [ 207.318205] __auxiliary_device_add+0x99/0x140 [ 207.318208] xe_nvm_init+0x7a2/0xef0 [xe] [ 207.318333] ? xe_devcoredump_init+0x80/0x110 [xe] [ 207.318452] ? __devm_add_action+0x82/0xc0 [ 207.318454] ? fs_reclaim_release+0xc0/0x110 [ 207.318457] xe_device_probe+0x17dd/0x2c40 [xe] [ 207.318574] ? __pfx___drm_dev_dbg+0x10/0x10 [ 207.318576] ? add_dr+0x180/0x220 [ 207.318579] ? __pfx___drmm_mutex_release+0x10/0x10 [ 207.318582] ? __pfx_xe_device_probe+0x10/0x10 [xe] [ 207.318697] ? xe_pm_init_early+0x33a/0x410 [xe] [ 207.318850] xe_pci_probe+0x936/0x1250 [xe] [ 207.318999] ? lock_acquire+0x1a4/0x2e0 [ 207.319003] ? __pfx_xe_pci_probe+0x10/0x10 [xe] [ 207.319151] local_pci_probe+0xe6/0x1a0 [ 207.319154] pci_device_probe+0x523/0x840 [ 207.319157] ? __pfx_pci_device_probe+0x10/0x10 [ 207.319159] ? sysfs_do_create_link_sd.isra.0+0x8c/0x110 [ 207.319162] ? sysfs_create_link+0x48/0xc0 ... " Fixes: c28bfb107dac ("drm/xe/nvm: add on-die non-volatile memory device") Reviewed-by: Alexander Usyskin <alexander.usyskin@intel.com> Reviewed-by: Brian Nguyen <brian3.nguyen@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Riana Tauro <riana.tauro@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260120183239.2966782-6-shuicheng.lin@intel.com (cherry picked from commit 11035eab1b7d88daa7904440046e64d3810b1ca1) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-29Merge tag 'mm-hotfixes-stable-2026-01-29-09-41' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "16 hotfixes. 9 are cc:stable, 12 are for MM. There's a patch series from Pratyush Yadav which fixes a few things in the new-in-6.19 LUO memfd code. Plus the usual shower of singletons - please see the changelogs for details" * tag 'mm-hotfixes-stable-2026-01-29-09-41' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: vmcoreinfo: make hwerr_data visible for debugging mm/zone_device: reinitialize large zone device private folios mm/mm_init: don't cond_resched() in deferred_init_memmap_chunk() if called from deferred_grow_zone() mm/kfence: randomize the freelist on initialization kho: kho_preserve_vmalloc(): don't return 0 when ENOMEM kho: init alloc tags when restoring pages from reserved memory mm: memfd_luo: restore and free memfd_luo_ser on failure mm: memfd_luo: use memfd_alloc_file() instead of shmem_file_setup() memfd: export alloc_file() flex_proportions: make fprop_new_period() hardirq safe mailmap: add entry for Viacheslav Bocharov mm/memory-failure: teach kill_accessing_process to accept hugetlb tail page pfn mm/memory-failure: fix missing ->mf_stats count in hugetlb poison mm, swap: restore swap_space attr aviod kernel panic mm/kasan: fix KASAN poisoning in vrealloc() mm/shmem, swap: fix race of truncate and swap entry split
2026-01-29drm/xe/multi_queue: Protect priority against concurrent accessNiranjana Vishwanathapura
Use a spinlock to protect multi-queue priority being concurrently updated by multiple set_priority ioctls and to protect against concurrent read and write to this field. v2: Update documentation, remove WRITE/READ_LOCK() (Thomas) Use scoped_guard, reduced lock scope (Matt Brost) v3: Fix author (checkpatch) Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260126174241.3470390-2-niranjana.vishwanathapura@intel.com
2026-01-29drm/bridge: imx8qxp-pixel-link: imx8qxp_pixel_link_find_next_bridge: return ↵Luca Ceresoli
int, not ERR_PTR In preparation for using bridge->next_bridge, we need to ensure that it will never contain anything but NULL or a valid bridge pointer. Current code stores an ERR_PTR when imx8qxp_pixel_link_find_next_bridge() errors out. Instead of fixing that after the facts in the caller, change the function to internally set pl->next_bridge and just return an int error value. No functional changes. Reviewed-by: Maxime Ripard <mripard@kernel.org> Acked-by: Liu Ying <victor.liu@nxp.com> Link: https://patch.msgid.link/20260107-drm-bridge-alloc-getput-drm_of_find_bridge-v4-3-a62b4399a6bf@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-01-29drm/bridge: imx8qxp-pixel-link: simplify freeing of the remote device_nodeLuca Ceresoli
The main loop in imx8qxp_pixel_link_find_next_bridge() requires calling of_node_put() in multiple places, complicating code flow. Simplify it by using a cleanup action and making the 'remote' variable scope local to the loop. Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Liu Ying <victor.liu@nxp.com> Link: https://patch.msgid.link/20260107-drm-bridge-alloc-getput-drm_of_find_bridge-v4-2-a62b4399a6bf@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>