Mauro Ribeiro
1a2e5454c2
arm/midgard: the kernel now provides MIN/MAX macros
2026-01-26 11:19:23 -03:00
Mauro Ribeiro
f5c4079f46
Merge tag 'v6.6.121' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.121 stable release
Change-Id: I48b846d6a48033969d0e0fe8d2af6594a1098152
2026-01-26 11:09:04 -03:00
Mauro Ribeiro
3ca62bf366
Merge tag 'v6.6.120' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.120 stable release
Change-Id: I99ea894d972989bd9ea303015666065815e69e55
2026-01-26 11:08:59 -03:00
Mauro Ribeiro
95e5649fa5
Merge tag 'v6.6.119' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.119 stable release
Change-Id: I5dc7616d912cd8e681fc325c273b02c3a46d5f29
2026-01-26 11:08:43 -03:00
Mauro Ribeiro
894779ec5e
Merge tag 'v6.6.118' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.118 stable release
2026-01-26 11:08:36 -03:00
Mauro Ribeiro
a0ccd67fc8
Merge tag 'v6.6.117' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.117 stable release
2026-01-26 11:08:03 -03:00
Mauro Ribeiro
ed54ef94b2
Merge tag 'v6.6.114' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.114 stable release
Change-Id: Ib8a998c659b719d601364eaf172493f627803d13
2026-01-26 11:03:39 -03:00
Mauro Ribeiro
0cbdeccf2c
Merge tag 'v6.6.113' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.113 stable release
Change-Id: I4a412403239fff2093312902be1bfe861e6b8f9b
2026-01-26 11:03:34 -03:00
Mauro Ribeiro
8f190dd586
Merge tag 'v6.6.112' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.112 stable release
Change-Id: I70575f702ed1a814308dd75ab676aab5dbbabe8e
2026-01-26 11:03:30 -03:00
Mauro Ribeiro
d30c17402a
Merge tag 'v6.6.109' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.109 stable release
Change-Id: Id3512e7832ef5d563ed94c36a4256b8e064eb534
2026-01-26 11:03:01 -03:00
Mauro Ribeiro
1e5fb82d69
Merge tag 'v6.6.108' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.108 stable release
Change-Id: Ic0efed400adae1e4d3381fe395320cedade9bdd5
2026-01-26 11:02:53 -03:00
Mauro Ribeiro
11dbace72b
Merge tag 'v6.6.107' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.107 stable release
Change-Id: I1a1d2fb009c6f0e708ba2318b2ab3bc8bcf5055f
2026-01-26 11:02:47 -03:00
Mauro Ribeiro
1e1f6569ad
Merge tag 'v6.6.105' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.105 stable release
Change-Id: I92b65bc2c9b14f6a13a8e4e9937d783e22a195cb
2026-01-26 11:02:36 -03:00
Mauro Ribeiro
70fa033544
Merge tag 'v6.6.104' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.104 stable release
Change-Id: I8012e0e6262bfe6c6cf5fc181f0beef8d2ed9d1a
2026-01-26 11:02:28 -03:00
Mauro Ribeiro
2c26575aec
Merge tag 'v6.6.103' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.103 stable release
Change-Id: I000cae00b799a6a3af191deb10b9c79c334035cd
2026-01-26 11:02:21 -03:00
Mauro Ribeiro
0a8a550fe0
Merge tag 'v6.6.102' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.102 stable release
Change-Id: I190d77ce588a35aedb1d5db4cb184c9800bfa844
2026-01-26 11:02:17 -03:00
Mauro Ribeiro
2990ca100c
Merge tag 'v6.6.101' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.101 stable release
Change-Id: I929f4b8ac20b7a7a37bff214d93e4a23f5c5c898
2026-01-26 11:02:07 -03:00
Mauro Ribeiro
93b4bf35bf
Merge tag 'v6.6.100' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.100 stable release
Change-Id: Iac981a894822934da552e66fa926222d7b6f24e5
2026-01-26 11:02:01 -03:00
Mauro Ribeiro
a6c8d978b7
Merge tag 'v6.6.99' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.99 stable release
2026-01-26 11:01:54 -03:00
Mauro Ribeiro
a53c34dd51
Merge tag 'v6.6.97' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.97 stable release
Change-Id: I261b5ee7814b7e7effc43ea662c4dbbdfb7a8139
2026-01-26 11:01:02 -03:00
Mauro Ribeiro
03d0244c54
Merge tag 'v6.6.96' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.96 stable release
Change-Id: I09386df319d05686b65001d77b83e6e62697ff33
2026-01-26 11:00:57 -03:00
Mauro Ribeiro
892f889f9f
Merge tag 'v6.6.95' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.95 stable release
Change-Id: Ia321e849ccb56e6f97b5f50f379d39b304108ffa
2026-01-26 11:00:51 -03:00
Mauro Ribeiro
1268a2baa9
Merge tag 'v6.6.94' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.94 stable release
Change-Id: I6be07d7b00cd13130141ecdb6d026e3d90ff6ea7
2026-01-26 11:00:47 -03:00
Charlene Liu
f73d929973
drm/amd/display: Fix DP no audio issue
...
[ Upstream commit 3886b198bd6e49c801fe9552fcfbfc387a49fbbc ]
[why]
need to enable APG_CLOCK_ENABLE enable first
also need to wake up az from D3 before access az block
Reviewed-by: Swapnil Patel <swapnil.patel@amd.com >
Signed-off-by: Charlene Liu <Charlene.Liu@amd.com >
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com >
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
(cherry picked from commit bf5e396957acafd46003318965500914d5f4edfa)
Signed-off-by: Sasha Levin <sashal@kernel.org >
2026-01-17 16:30:01 +01:00
Alex Deucher
e23882b11f
drm/radeon: Remove __counted_by from ClockInfoArray.clockInfo[]
...
commit 19158c7332468bc28572bdca428e89c7954ee1b1 upstream.
clockInfo[] is a generic uchar pointer to variable sized structures
which vary from ASIC to ASIC.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4374
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
(cherry picked from commit dc135aa73561b5acc74eadf776e48530996529a3)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-17 16:29:53 +01:00
Miaoqian Lin
526bd4bfa1
drm/pl111: Fix error handling in pl111_amba_probe
...
commit 0ddd3bb4b14c9102c0267b3fd916c81fe5ab89c1 upstream.
Jump to the existing dev_put label when devm_request_irq() fails
so drm_dev_put() and of_reserved_mem_device_release() run
instead of returning early and leaking resources.
Found via static analysis and code review.
Fixes: bed41005e6stable@vger.kernel.org
Signed-off-by: Miaoqian Lin <linmq006@gmail.com >
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com >
Signed-off-by: Linus Walleij <linusw@kernel.org >
Link: https://patch.msgid.link/20251211123345.2392065-1-linmq006@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-17 16:29:53 +01:00
Aurabindo Pillai
6940c1d0c8
drm/amd/display: Fix null pointer deref in dcn20_resource.c
...
[ Upstream commit ecbf60782662f0a388493685b85a645a0ba1613c ]
Fixes a hang thats triggered when MPV is run on a DCN401 dGPU:
mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all
and then enabling fullscreen playback (double click on the video)
The following calltrace will be seen:
[ 181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 181.843997] #PF: supervisor instruction fetch in kernel mode
[ 181.844003] #PF: error_code(0x0010) - not-present page
[ 181.844009] PGD 0 P4D 0
[ 181.844020] Oops: 0010 [#1 ] PREEMPT SMP NOPTI
[ 181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu
[ 181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018
[ 181.844044] RIP: 0010:0x0
[ 181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246
[ 181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004
[ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400
[ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c
[ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8
[ 181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005
[ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000
[ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0
[ 181.844141] Call Trace:
[ 181.844146] <TASK>
[ 181.844153] ? show_regs+0x6d/0x80
[ 181.844167] ? __die+0x24/0x80
[ 181.844179] ? page_fault_oops+0x99/0x1b0
[ 181.844192] ? do_user_addr_fault+0x31d/0x6b0
[ 181.844204] ? exc_page_fault+0x83/0x1b0
[ 181.844216] ? asm_exc_page_fault+0x27/0x30
[ 181.844237] dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu]
[ 181.845115] amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu]
[ 181.845985] amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu]
[ 181.846848] fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu]
[ 181.847734] fill_dc_plane_attributes+0x162/0x350 [amdgpu]
[ 181.848748] dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]
[ 181.849791] ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]
[ 181.850840] amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu]
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com >
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
Signed-off-by: David Nyström <david.nystrom@est.tech >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:25 +01:00
Kory Maincent (TI.com)
21e52dc776
drm/tilcdc: Fix removal actions in case of failed probe
...
[ Upstream commit a585c7ef9cabda58088916baedc6573e9a5cd2a7 ]
The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers
should only be called when the device has been successfully registered.
Currently, these functions are called unconditionally in tilcdc_fini(),
which causes warnings during probe deferral scenarios.
[ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68
...
[ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108
[ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8
[ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144
[ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc]
[ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc]
Fix this by rewriting the failed probe cleanup path using the standard
goto error handling pattern, which ensures that cleanup functions are
only called on successfully initialized resources. Additionally, remove
the now-unnecessary is_registered flag.
Cc: stable@vger.kernel.org
Fixes: 3c4babae3c4a ("drm: Call drm_atomic_helper_shutdown() at shutdown/remove time for misc drivers")
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com >
Reviewed-by: Douglas Anderson <dianders@chromium.org >
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com >
Signed-off-by: Douglas Anderson <dianders@chromium.org >
Link: https://patch.msgid.link/20251125090546.137193-1-kory.maincent@bootlin.com
Signed-off-by: Sasha Levin <sashal@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:25 +01:00
Philipp Stanner
5bc791132f
drm/tilcdc: request and mapp iomem with devres
...
[ Upstream commit a196a5166e0812db267281c32fa0724fc5be6582 ]
tilcdc currently just ioremaps its iomem, without doing the (a bit more
robust) request on the memory first. The devm_ functions provide a handy
way to both request and ioremap the memory with automatic cleanup.
Replace the manual ioremap with the devm_ version.
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de >
Signed-off-by: Philipp Stanner <pstanner@redhat.com >
Reviewed-by: Jyri Sarha <jyri.sarha@iki.fi >
Tested-by: Jyri Sarha <jyri.sarha@iki.fi >
Signed-off-by: Jyri Sarha <jyri.sarha@iki.fi >
Link: https://patchwork.freedesktop.org/patch/msgid/20231222115216.19218-2-pstanner@redhat.com
Stable-dep-of: a585c7ef9cab ("drm/tilcdc: Fix removal actions in case of failed probe")
Signed-off-by: Sasha Levin <sashal@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:25 +01:00
Johan Hovold
205aa0c83c
drm/mediatek: Fix probe resource leaks
...
[ Upstream commit 07c7c640a8eb9e196f357d15d88a59602a947197 ]
Make sure to unmap and release the component iomap and clock on probe
failure (e.g. probe deferral) and on driver unbind.
Note that unlike of_iomap(), devm_of_iomap() also checks whether the
region is already mapped.
Fixes: 119f517362stable@vger.kernel.org # 4.7
Cc: CK Hu <ck.hu@mediatek.com >
Signed-off-by: Johan Hovold <johan@kernel.org >
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com >
Link: https://patchwork.kernel.org/project/dri-devel/patch/20250923152340.18234-2-johan@kernel.org/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org >
Signed-off-by: Sasha Levin <sashal@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:24 +01:00
Johan Hovold
fef6d1474a
drm/mediatek: Fix probe memory leak
...
[ Upstream commit 5e49200593f331cd0629b5376fab9192f698e8ef ]
The Mediatek DRM driver allocates private data for components without a
platform driver but as the lifetime is tied to each component device,
the memory is never freed.
Tie the allocation lifetime to the DRM platform device so that the
memory is released on probe failure (e.g. probe deferral) and when the
driver is unbound.
Fixes: c0d36de868stable@vger.kernel.org # 5.12
Cc: CK Hu <ck.hu@mediatek.com >
Signed-off-by: Johan Hovold <johan@kernel.org >
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com >
Link: https://patchwork.kernel.org/project/dri-devel/patch/20250923152340.18234-3-johan@kernel.org/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org >
Signed-off-by: Sasha Levin <sashal@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:24 +01:00
Natalie Vock
11dba925f5
drm/amdgpu: Forward VMID reservation errors
...
[ Upstream commit 8defb4f081a5feccc3ea8372d0c7af3522124e1f ]
Otherwise userspace may be fooled into believing it has a reserved VMID
when in reality it doesn't, ultimately leading to GPU hangs when SPM is
used.
Fixes: 80e709ee6estable@vger.kernel.org
Reviewed-by: Christian König <christian.koenig@amd.com >
Signed-off-by: Natalie Vock <natalie.vock@gmx.de >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
[ adapted 3-argument amdgpu_vmid_alloc_reserved(adev, vm, vmhub) call to 2-argument version and added separate error check to preserve reserved_vmid tracking logic. ]
Signed-off-by: Sasha Levin <sashal@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:24 +01:00
Lyude Paul
23525fc0ea
drm/nouveau/dispnv50: Don't call drm_atomic_get_crtc_state() in prepare_fb
...
commit 560271e10b2c86e95ea35afa9e79822e4847f07a upstream.
Since we recently started warning about uses of this function after the
atomic check phase completes, we've started getting warnings about this in
nouveau. It appears a misplaced drm_atomic_get_crtc_state() call has been
hiding in our .prepare_fb callback for a while.
So, fix this by adding a new nv50_head_atom_get_new() function and use that
in our .prepare_fb callback instead.
Signed-off-by: Lyude Paul <lyude@redhat.com >
Reviewed-by: Dave Airlie <airlied@redhat.com >
Fixes: 1590700d94stable@vger.kernel.org > # v4.18+
Link: https://patch.msgid.link/20251211190256.396742-1-lyude@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:20 +01:00
Krzysztof Niemiec
0336188cc8
drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer
...
commit 4fe2bd195435e71c117983d87f278112c5ab364c upstream.
Initialize the eb.vma array with values of 0 when the eb structure is
first set up. In particular, this sets the eb->vma[i].vma pointers to
NULL, simplifying cleanup and getting rid of the bug described below.
During the execution of eb_lookup_vmas(), the eb->vma array is
successively filled up with struct eb_vma objects. This process includes
calling eb_add_vma(), which might fail; however, even in the event of
failure, eb->vma[i].vma is set for the currently processed buffer.
If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which
prompts a call to eb_release_vmas() to clean up the mess. Since
eb_lookup_vmas() might fail during processing any (possibly not first)
buffer, eb_release_vmas() checks whether a buffer's vma is NULL to know
at what point did the lookup function fail.
In eb_lookup_vmas(), eb->vma[i].vma is set to NULL if either the helper
function eb_lookup_vma() or eb_validate_vma() fails. eb->vma[i+1].vma is
set to NULL in case i915_gem_object_userptr_submit_init() fails; the
current one needs to be cleaned up by eb_release_vmas() at this point,
so the next one is set. If eb_add_vma() fails, neither the current nor
the next vma is set to NULL, which is a source of a NULL deref bug
described in the issue linked in the Closes tag.
When entering eb_lookup_vmas(), the vma pointers are set to the slab
poison value, instead of NULL. This doesn't matter for the actual
lookup, since it gets overwritten anyway, however the eb_release_vmas()
function only recognizes NULL as the stopping value, hence the pointers
are being set to NULL as they go in case of intermediate failure. This
patch changes the approach to filling them all with NULL at the start
instead, rather than handling that manually during failure.
Reported-by: Gangmin Kim <km.kim1503@gmail.com >
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15062
Fixes: 544460c338stable@vger.kernel.org # 5.16.x
Signed-off-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com >
Reviewed-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com >
Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com >
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com >
Signed-off-by: Andi Shyti <andi.shyti@kernel.org >
Link: https://lore.kernel.org/r/20251216180900.54294-2-krzysztof.niemiec@intel.com
(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:19 +01:00
Nikolay Kuratov
678d1c8656
drm/msm/dpu: Add missing NULL pointer check for pingpong interface
...
commit 88733a0b64872357e5ecd82b7488121503cb9cc6 upstream.
It is checked almost always in dpu_encoder_phys_wb_setup_ctl(), but in a
single place the check is missing.
Also use convenient locals instead of phys_enc->* where available.
Cc: stable@vger.kernel.org
Fixes: d7d0e73f7dkniv@yandex-team.ru >
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com >
Patchwork: https://patchwork.freedesktop.org/patch/693860/
Link: https://lore.kernel.org/r/20251211093630.171014-1-kniv@yandex-team.ru
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:19 +01:00
René Rebe
56f07bc0a0
drm/mgag200: Fix big-endian support
...
commit 6cb31fba137d45e682ce455b8ea364f44d5d4f98 upstream.
Unlike the original, deleted Matrox mga driver, the new mgag200 driver
has the XRGB frame-buffer byte swapped on big-endian "RISC"
systems. Fix by enabling byte swapping "PowerPC" OPMODE for any
__BIG_ENDIAN config.
Fixes: 414c453106rene@exactco.de >
Cc: stable@kernel.org
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de >
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de >
Link: https://patch.msgid.link/20251208.141827.965103015954471168.rene@exactco.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:19 +01:00
Simon Richter
3d004f7341
drm/ttm: Avoid NULL pointer deref for evicted BOs
...
commit 491adc6a0f9903c32b05f284df1148de39e8e644 upstream.
It is possible for a BO to exist that is not currently associated with a
resource, e.g. because it has been evicted.
When devcoredump tries to read the contents of all BOs for dumping, we need
to expect this as well -- in this case, ENODATA is recorded instead of the
buffer contents.
Fixes: 7d08df5d0bd3 ("drm/ttm: Add ttm_bo_access")
Fixes: 09ac4fcb3fstable@kernel.org >
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6271
Signed-off-by: Simon Richter <Simon.Richter@hogyros.de >
Reviewed-by: Matthew Brost <matthew.brost@intel.com >
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com >
Reviewed-by: Christian König <christian.koenig@amd.com >
Signed-off-by: Matthew Brost <matthew.brost@intel.com >
Link: https://patch.msgid.link/20251013161241.709916-1-Simon.Richter@hogyros.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:19 +01:00
Miaoqian Lin
3144af03d5
drm/mediatek: Fix device node reference leak in mtk_dp_dt_parse()
...
commit a846505a193d7492ad3531e33cacfca31e4bcdd1 upstream.
The function mtk_dp_dt_parse() calls of_graph_get_endpoint_by_regs()
to get the endpoint device node, but fails to call of_node_put() to release
the reference when the function returns. This results in a device node
reference leak.
Fix this by adding the missing of_node_put() call before returning from
the function.
Found via static analysis and code review.
Fixes: f70ac097a2stable@vger.kernel.org
Signed-off-by: Miaoqian Lin <linmq006@gmail.com >
Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com >
Reviewed-by: CK Hu <ck.hu@mediatek.com >
Link: https://patchwork.kernel.org/project/dri-devel/patch/20251029072307.10955-1-linmq006@gmail.com/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:19 +01:00
Thomas Zimmermann
ed51ddd5d4
drm/gma500: Remove unused helper psb_fbdev_fb_setcolreg()
...
commit be729f9de6c64240645dc80a24162ac4d3fe00a8 upstream.
Remove psb_fbdev_fb_setcolreg(), which hasn't been called in almost
a decade.
Gma500 commit 4d8d096e9a3da6c2f3b73da6c2f3b7patrik.r.jakobsson@gmail.com >
Cc: Stefan Christ <contact@stefanchrist.eu >
Cc: Daniel Vetter <daniel.vetter@ffwll.ch >
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org > # v4.10+
Link: https://elixir.bootlin.com/linux/v6.16.9/source/drivers/video/fbdev/core/fbcmap.c#L246 # [1]
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de >
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com >
Link: https://lore.kernel.org/r/20250929082338.18845-1-tzimmermann@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:19 +01:00
Akhil P Oommen
f691636311
drm/msm/a6xx: Fix out of bound IO access in a6xx_get_gmu_registers
...
commit 779b68a5bf2764c8ed3aa800e41ba0d5d007e1e7 upstream.
REG_A6XX_GMU_AO_AHB_FENCE_CTRL register falls under GMU's register
range. So, use gmu_write() routines to write to this register.
Fixes: 1707add815stable@vger.kernel.org
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com >
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com >
Patchwork: https://patchwork.freedesktop.org/patch/688993/
Message-ID: <20251118-kaana-gpu-support-v4-1-86eeb8e93fb6@oss.qualcomm.com >
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:19 +01:00
Pierre-Eric Pelloux-Prayer
e05d53454b
drm/amdgpu: add missing lock to amdgpu_ttm_access_memory_sdma
...
commit 4fa944255be521b1bbd9780383f77206303a3a5c upstream.
Users of ttm entities need to hold the gtt_window_lock before using them
to guarantee proper ordering of jobs.
Cc: stable@vger.kernel.org
Fixes: cb5cc4f573pierre-eric.pelloux-prayer@amd.com >
Reviewed-by: Christian König <christian.koenig@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:19 +01:00
Alex Deucher
4cd6081860
drm/amd/display: Use GFP_ATOMIC in dc_create_plane_state()
...
commit 3c41114dcdabb7b25f5bc33273c6db9c7af7f4a7 upstream.
This can get called from an atomic context.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4470
Reviewed-by: Harry Wentland <harry.wentland@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
(cherry picked from commit 8acdad9344cc7b4e7bc01f0dfea80093eb3768db)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2026-01-11 15:22:03 +01:00
Marijn Suijten
86fcc629fd
drm/panel: sony-td4353-jdi: Enable prepare_prev_first
...
[ Upstream commit 2b973ca48ff3ef1952091c8f988d7796781836c8 ]
The DSI host must be enabled before our prepare function can run, which
has to send its init sequence over DSI. Without enabling the host first
the panel will not probe.
Fixes: 9e15123ecamarijn.suijten@somainline.org >
Reviewed-by: Douglas Anderson <dianders@chromium.org >
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com >
Reviewed-by: Martin Botka <martin.botka@somainline.org >
Signed-off-by: Douglas Anderson <dianders@chromium.org >
Link: https://patch.msgid.link/20251130-sony-akari-fix-panel-v1-1-1d27c60a55f5@somainline.org
Signed-off-by: Sasha Levin <sashal@kernel.org >
2026-01-11 15:21:48 +01:00
Dan Carpenter
e84690a05e
drm/amd/display: Fix logical vs bitwise bug in get_embedded_panel_info_v2_1()
...
[ Upstream commit 1a79482699b4d1e43948d14f0c7193dc1dcad858 ]
The .H_SYNC_POLARITY and .V_SYNC_POLARITY variables are 1 bit bitfields
of a u32. The ATOM_HSYNC_POLARITY define is 0x2 and the
ATOM_VSYNC_POLARITY is 0x4. When we do a bitwise negate of 0, 2, or 4
then the last bit is always 1 so this code always sets .H_SYNC_POLARITY
and .V_SYNC_POLARITY to true.
This code is instead intended to check if the ATOM_HSYNC_POLARITY or
ATOM_VSYNC_POLARITY flags are set and reverse the result. In other
words, it's supposed to be a logical negate instead of a bitwise negate.
Fixes: ae79c310b1dan.carpenter@linaro.org >
Reviewed-by: Alex Hung <alex.hung@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2026-01-11 15:21:31 +01:00
Timur Tabi
7e50ce619e
drm/nouveau: restrict the flush page to a 32-bit address
...
[ Upstream commit 04d98b3452331fa53ec3b698b66273af6ef73288 ]
The flush page DMA address is stored in a special register that is not
associated with the GPU's standard DMA range. For example, on Turing,
the GPU's MMU can handle 47-bit addresses, but the flush page address
register is limited to 40 bits.
At the point during device initialization when the flush page is
allocated, the DMA mask is still at its default of 32 bits. So even
though it's unlikely that the flush page could exist above a 40-bit
address, the dma_map_page() call could fail, e.g. if IOMMU is disabled
and the address is above 32 bits. The simplest way to achieve all
constraints is to allocate the page in the DMA32 zone. Since the flush
page is literally just a page, this is an acceptable limitation. The
alternative is to temporarily set the DMA mask to 40 (or 52 for Hopper
and later) bits, but that could have unforseen side effects.
In situations where the flush page is allocated above 32 bits and IOMMU
is disabled, you will get an error like this:
nouveau 0000:65:00.0: DMA addr 0x0000000107c56000+4096 overflow (mask ffffffff, bus limit 0).
Fixes: 5728d06419ttabi@nvidia.com >
Reviewed-by: Lyude Paul <lyude@redhat.com >
Signed-off-by: Lyude Paul <lyude@redhat.com >
Link: https://patch.msgid.link/20251113230323.1271726-1-ttabi@nvidia.com
Signed-off-by: Sasha Levin <sashal@kernel.org >
2026-01-11 15:21:30 +01:00
Jay Liu
d258ebe705
drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue
...
[ Upstream commit 20ac36b71c53b8c36c6903b5ca87c75226700a97 ]
if matrixbit is 11,
The range of color matrix is from 0 to (BIT(12) - 1).
Values from 0 to (BIT(11) - 1) represent positive numbers,
values from BIT(11) to (BIT(12) - 1) represent negative numbers.
For example, -1 need converted to 8191.
so convert S31.32 to HW Q2.11 format by drm_color_ctm_s31_32_to_qm_n,
and set int_bits to 2.
Fixes: 738ed4156fangelogioacchino.delregno@collabora.com >
Signed-off-by: Jay Liu <jay.liu@mediatek.com >
Link: https://patchwork.kernel.org/project/dri-devel/patch/20250921055416.25588-2-jay.liu@mediatek.com/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2026-01-11 15:21:26 +01:00
Dmitry Baryshkov
5ed033c541
drm/msm/a2xx: stop over-complaining about the legacy firmware
...
[ Upstream commit a3a22373fce576560757f5616eb48dbf85891d9c ]
If the rootfs have a legacy A200 firmware, currently the driver will
complain each time the hw is reinited (which can happen a lot). E.g.
with GL testsuite the hw is reinited after each test, spamming the
console.
Make sure that the message is printed only once: when we detect the
firmware that doesn't support protection.
Fixes: 302295070ddmitry.baryshkov@oss.qualcomm.com >
Patchwork: https://patchwork.freedesktop.org/patch/688098/
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2026-01-11 15:21:25 +01:00
Janusz Krzysztofik
9dc3c78d21
drm/vgem-fence: Fix potential deadlock on release
...
[ Upstream commit 78b4d6463e9e69e5103f98b367f8984ad12cdc6f ]
A timer that expires a vgem fence automatically in 10 seconds is now
released with timer_delete_sync() from fence->ops.release() called on last
dma_fence_put(). In some scenarios, it can run in IRQ context, which is
not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was
demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while
working on new IGT subtests syncobj_timeline@stress-* as user space
replacements of some problematic test cases of a dma-fence-chain selftest
[1].
[117.004338] ================================
[117.004340] WARNING: inconsistent lock state
[117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U
[117.004346] --------------------------------
[117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes:
[117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190
[117.004361] {HARDIRQ-ON-W} state was registered at:
[117.004363] lock_acquire+0xc4/0x2e0
[117.004366] call_timer_fn+0x80/0x2a0
[117.004368] __run_timers+0x231/0x310
[117.004370] run_timer_softirq+0x76/0xe0
[117.004372] handle_softirqs+0xd4/0x4d0
[117.004375] __irq_exit_rcu+0x13f/0x160
[117.004377] irq_exit_rcu+0xe/0x20
[117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0
[117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20
[117.004385] cpuidle_enter_state+0x12b/0x8a0
[117.004388] cpuidle_enter+0x2e/0x50
[117.004393] call_cpuidle+0x22/0x60
[117.004395] do_idle+0x1fd/0x260
[117.004398] cpu_startup_entry+0x29/0x30
[117.004401] start_secondary+0x12d/0x160
[117.004404] common_startup_64+0x13e/0x141
[117.004407] irq event stamp: 2282669
[117.004409] hardirqs last enabled at (2282668): [<ffffffff8289db71>] _raw_spin_unlock_irqrestore+0x51/0x80
[117.004414] hardirqs last disabled at (2282669): [<ffffffff82882021>] sysvec_irq_work+0x11/0xc0
[117.004419] softirqs last enabled at (2254702): [<ffffffff8289fd00>] __do_softirq+0x10/0x18
[117.004423] softirqs last disabled at (2254725): [<ffffffff813d4ddf>] __irq_exit_rcu+0x13f/0x160
[117.004426]
other info that might help us debug this:
[117.004429] Possible unsafe locking scenario:
[117.004432] CPU0
[117.004433] ----
[117.004434] lock((&fence->timer));
[117.004436] <Interrupt>
[117.004438] lock((&fence->timer));
[117.004440]
*** DEADLOCK ***
[117.004443] 1 lock held by swapper/0/0:
[117.004445] #0 : ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0
[117.004450]
stack backtrace:
[117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary)
[117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER
[117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
[117.004456] Call Trace:
[117.004456] <IRQ>
[117.004457] dump_stack_lvl+0x91/0xf0
[117.004460] dump_stack+0x10/0x20
[117.004461] print_usage_bug.part.0+0x260/0x360
[117.004463] mark_lock+0x76e/0x9c0
[117.004465] ? register_lock_class+0x48/0x4a0
[117.004467] __lock_acquire+0xbc3/0x2860
[117.004469] lock_acquire+0xc4/0x2e0
[117.004470] ? __timer_delete_sync+0x4b/0x190
[117.004472] ? __timer_delete_sync+0x4b/0x190
[117.004473] __timer_delete_sync+0x68/0x190
[117.004474] ? __timer_delete_sync+0x4b/0x190
[117.004475] timer_delete_sync+0x10/0x20
[117.004476] vgem_fence_release+0x19/0x30 [vgem]
[117.004478] dma_fence_release+0xc1/0x3b0
[117.004480] ? dma_fence_release+0xa1/0x3b0
[117.004481] dma_fence_chain_release+0xe7/0x130
[117.004483] dma_fence_release+0xc1/0x3b0
[117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80
[117.004485] dma_fence_chain_irq_work+0x59/0x80
[117.004487] irq_work_single+0x75/0xa0
[117.004490] irq_work_run_list+0x33/0x60
[117.004491] irq_work_run+0x18/0x40
[117.004493] __sysvec_irq_work+0x35/0x170
[117.004494] sysvec_irq_work+0x47/0xc0
[117.004496] asm_sysvec_irq_work+0x1b/0x20
[117.004497] RIP: 0010:_raw_spin_unlock_irqrestore+0x57/0x80
[117.004499] Code: 00 75 1c 65 ff 0d d9 34 68 01 74 20 5b 41 5c 5d 31 c0 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc e8 7f 9d d3 fe fb 0f 1f 44 00 00 <eb> d7 0f 1f 44 00 00 5b 41 5c 5d 31 c0 31 d2 31 c9 31 f6 31 ff c3
[117.004499] RSP: 0018:ffffc90000003cf0 EFLAGS: 00000246
[117.004500] RAX: 0000000000000000 RBX: ffff888155e94c40 RCX: 0000000000000000
[117.004501] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[117.004502] RBP: ffffc90000003d00 R08: 0000000000000000 R09: 0000000000000000
[117.004502] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000246
[117.004502] R13: 0000000000000001 R14: 0000000000000246 R15: ffff888155e94c80
[117.004506] dma_fence_signal+0x49/0xb0
[117.004507] ? __pfx_vgem_fence_timeout+0x10/0x10 [vgem]
[117.004508] vgem_fence_timeout+0x12/0x20 [vgem]
[117.004509] call_timer_fn+0xa1/0x2a0
[117.004512] ? __pfx_vgem_fence_timeout+0x10/0x10 [vgem]
[117.004513] __run_timers+0x231/0x310
[117.004514] ? tmigr_handle_remote+0x2ac/0x560
[117.004517] timer_expire_remote+0x46/0x70
[117.004518] tmigr_handle_remote+0x433/0x560
[117.004520] ? __run_timers+0x239/0x310
[117.004521] ? run_timer_softirq+0x21/0xe0
[117.004522] ? lock_release+0xce/0x2a0
[117.004524] run_timer_softirq+0xcf/0xe0
[117.004525] handle_softirqs+0xd4/0x4d0
[117.004526] __irq_exit_rcu+0x13f/0x160
[117.004527] irq_exit_rcu+0xe/0x20
[117.004528] sysvec_apic_timer_interrupt+0xa0/0xc0
[117.004529] </IRQ>
[117.004529] <TASK>
[117.004529] asm_sysvec_apic_timer_interrupt+0x1b/0x20
[117.004530] RIP: 0010:cpuidle_enter_state+0x12b/0x8a0
[117.004532] Code: 48 0f a3 05 97 ce 0e 01 0f 82 2e 03 00 00 31 ff e8 8a 41 bd fe 80 7d d0 00 0f 85 11 03 00 00 e8 8b 06 d5 fe fb 0f 1f 44 00 00 <45> 85 f6 0f 88 67 02 00 00 4d 63 ee 49 83 fd 0a 0f 83 34 06 00 00
[117.004532] RSP: 0018:ffffffff83403d88 EFLAGS: 00000246
[117.004533] RAX: 0000000000000000 RBX: ffff88888f046440 RCX: 0000000000000000
[117.004533] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[117.004534] RBP: ffffffff83403dd8 R08: 0000000000000000 R09: 0000000000000000
[117.004534] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff837cbe80
[117.004534] R13: 0000000000000004 R14: 0000000000000004 R15: 0000001ad1df466b
[117.004537] ? cpuidle_enter_state+0x125/0x8a0
[117.004538] ? sched_clock_noinstr+0x9/0x10
[117.004540] cpuidle_enter+0x2e/0x50
[117.004542] call_cpuidle+0x22/0x60
[117.004542] do_idle+0x1fd/0x260
[117.004544] cpu_startup_entry+0x29/0x30
[117.004546] rest_init+0x104/0x200
[117.004548] start_kernel+0x93d/0xbd0
[117.004550] ? load_ucode_intel_bsp+0x2a/0x90
[117.004551] ? sme_unmap_bootdata+0x14/0x80
[117.004554] x86_64_start_reservations+0x18/0x30
[117.004555] x86_64_start_kernel+0xfd/0x150
[117.004556] ? soft_restart_cpu+0x14/0x14
[117.004558] common_startup_64+0x13e/0x141
[117.004560] </TASK>
[117.004565] ------------[ cut here ]------------
[117.004692] WARNING: CPU: 0 PID: 0 at kernel/time/timer.c:1610 __timer_delete_sync+0x126/0x190
[117.004697] Modules linked in: vgem snd_hda_codec_intelhdmi snd_hda_codec_hdmi i915 prime_numbers ttm drm_buddy drm_display_helper cec rc_core i2c_algo_bit hid_sensor_custom hid_sensor_hub hid_generic intel_ishtp_hid hid intel_uncore_frequency intel_uncore_frequency_common x86_pkg_temp_thermal intel_powerclamp cmdlinepart ee1004 r8153_ecm spi_nor coretemp cdc_ether mei_pxp mei_hdcp usbnet mtd intel_rapl_msr wmi_bmof kvm_intel snd_hda_intel snd_intel_dspcfg processor_thermal_device_pci kvm snd_hda_codec processor_thermal_device irqbypass processor_thermal_wt_hint polyval_clmulni platform_temperature_control snd_hda_core ghash_clmulni_intel processor_thermal_rfim spi_pxa2xx_platform snd_hwdep aesni_intel processor_thermal_rapl dw_dmac snd_pcm dw_dmac_core intel_rapl_common r8152 rapl mii intel_cstate spi_pxa2xx_core i2c_i801 processor_thermal_wt_req snd_timer i2c_mux mei_me intel_ish_ipc processor_thermal_power_floor e1000e snd i2c_smbus spi_intel_pci processor_thermal_mbox mei soundcore intel_ishtp thunderbolt idma64
[117.004733] spi_intel int340x_thermal_zone igen6_edac binfmt_misc intel_skl_int3472_tps68470 intel_pmc_core tps68470_regulator video clk_tps68470 pmt_telemetry pmt_discovery nls_iso8859_1 pmt_class intel_pmc_ssram_telemetry intel_skl_int3472_discrete int3400_thermal intel_hid intel_skl_int3472_common acpi_thermal_rel intel_vsec wmi pinctrl_tigerlake acpi_tad sparse_keymap acpi_pad dm_multipath msr nvme_fabrics fuse efi_pstore nfnetlink autofs4
[117.004782] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary)
[117.004787] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER
[117.004789] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
[117.004793] RIP: 0010:__timer_delete_sync+0x126/0x190
[117.004795] Code: 31 c0 45 31 c9 c3 cc cc cc cc 48 8b 75 d0 45 84 f6 74 63 49 c7 45 18 00 00 00 00 48 89 c7 e8 51 46 39 01 f3 90 e9 66 ff ff ff <0f> 0b e9 5f ff ff ff e8 ee e4 0c 00 49 8d 5d 28 45 31 c9 31 c9 4c
[117.004801] RSP: 0018:ffffc90000003a40 EFLAGS: 00010046
[117.004804] RAX: ffffffff815093fb RBX: ffff888138f86aa8 RCX: 0000000000000000
[117.004807] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[117.004809] RBP: ffffc90000003a70 R08: 0000000000000000 R09: 0000000000000000
[117.004812] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff815093fb
[117.004814] R13: ffff888138f86a80 R14: 0000000000000000 R15: 0000000000000000
[117.004817] FS: 0000000000000000(0000) GS:ffff88890b0f7000(0000) knlGS:0000000000000000
[117.004820] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[117.004823] CR2: 00005db8131eb7f0 CR3: 0000000003448000 CR4: 0000000000f52ef0
[117.004826] PKRU: 55555554
[117.004827] Call Trace:
[117.004829] <IRQ>
[117.004831] timer_delete_sync+0x10/0x20
[117.004833] vgem_fence_release+0x19/0x30 [vgem]
[117.004836] dma_fence_release+0xc1/0x3b0
[117.004838] ? dma_fence_release+0xa1/0x3b0
[117.004841] dma_fence_chain_release+0xe7/0x130
[117.004844] dma_fence_release+0xc1/0x3b0
[117.004847] ? _raw_spin_unlock_irqrestore+0x27/0x80
[117.004850] dma_fence_chain_irq_work+0x59/0x80
[117.004853] irq_work_single+0x75/0xa0
[117.004857] irq_work_run_list+0x33/0x60
[117.004860] irq_work_run+0x18/0x40
[117.004863] __sysvec_irq_work+0x35/0x170
[117.004865] sysvec_irq_work+0x47/0xc0
[117.004868] asm_sysvec_irq_work+0x1b/0x20
[117.004871] RIP: 0010:_raw_spin_unlock_irqrestore+0x57/0x80
[117.004874] Code: 00 75 1c 65 ff 0d d9 34 68 01 74 20 5b 41 5c 5d 31 c0 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc e8 7f 9d d3 fe fb 0f 1f 44 00 00 <eb> d7 0f 1f 44 00 00 5b 41 5c 5d 31 c0 31 d2 31 c9 31 f6 31 ff c3
[117.004879] RSP: 0018:ffffc90000003cf0 EFLAGS: 00000246
[117.004882] RAX: 0000000000000000 RBX: ffff888155e94c40 RCX: 0000000000000000
[117.004884] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[117.004887] RBP: ffffc90000003d00 R08: 0000000000000000 R09: 0000000000000000
[117.004890] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000246
[117.004892] R13: 0000000000000001 R14: 0000000000000246 R15: ffff888155e94c80
[117.004897] dma_fence_signal+0x49/0xb0
[117.004899] ? __pfx_vgem_fence_timeout+0x10/0x10 [vgem]
[117.004902] vgem_fence_timeout+0x12/0x20 [vgem]
[117.004904] call_timer_fn+0xa1/0x2a0
[117.004908] ? __pfx_vgem_fence_timeout+0x10/0x10 [vgem]
[117.004910] __run_timers+0x231/0x310
[117.004913] ? tmigr_handle_remote+0x2ac/0x560
[117.004917] timer_expire_remote+0x46/0x70
[117.004919] tmigr_handle_remote+0x433/0x560
[117.004923] ? __run_timers+0x239/0x310
[117.004925] ? run_timer_softirq+0x21/0xe0
[117.004928] ? lock_release+0xce/0x2a0
[117.004931] run_timer_softirq+0xcf/0xe0
[117.004933] handle_softirqs+0xd4/0x4d0
[117.004936] __irq_exit_rcu+0x13f/0x160
[117.004938] irq_exit_rcu+0xe/0x20
[117.004940] sysvec_apic_timer_interrupt+0xa0/0xc0
[117.004943] </IRQ>
[117.004944] <TASK>
[117.004946] asm_sysvec_apic_timer_interrupt+0x1b/0x20
[117.004949] RIP: 0010:cpuidle_enter_state+0x12b/0x8a0
[117.004953] Code: 48 0f a3 05 97 ce 0e 01 0f 82 2e 03 00 00 31 ff e8 8a 41 bd fe 80 7d d0 00 0f 85 11 03 00 00 e8 8b 06 d5 fe fb 0f 1f 44 00 00 <45> 85 f6 0f 88 67 02 00 00 4d 63 ee 49 83 fd 0a 0f 83 34 06 00 00
[117.004961] RSP: 0018:ffffffff83403d88 EFLAGS: 00000246
[117.004963] RAX: 0000000000000000 RBX: ffff88888f046440 RCX: 0000000000000000
[117.004966] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[117.004968] RBP: ffffffff83403dd8 R08: 0000000000000000 R09: 0000000000000000
[117.004971] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff837cbe80
[117.004974] R13: 0000000000000004 R14: 0000000000000004 R15: 0000001ad1df466b
[117.004978] ? cpuidle_enter_state+0x125/0x8a0
[117.004981] ? sched_clock_noinstr+0x9/0x10
[117.004985] cpuidle_enter+0x2e/0x50
[117.004989] call_cpuidle+0x22/0x60
[117.004991] do_idle+0x1fd/0x260
[117.005001] cpu_startup_entry+0x29/0x30
[117.005004] rest_init+0x104/0x200
[117.005008] start_kernel+0x93d/0xbd0
[117.005011] ? load_ucode_intel_bsp+0x2a/0x90
[117.005014] ? sme_unmap_bootdata+0x14/0x80
[117.005017] x86_64_start_reservations+0x18/0x30
[117.005020] x86_64_start_kernel+0xfd/0x150
[117.005023] ? soft_restart_cpu+0x14/0x14
[117.005026] common_startup_64+0x13e/0x141
[117.005030] </TASK>
[117.005032] irq event stamp: 2282669
[117.005034] hardirqs last enabled at (2282668): [<ffffffff8289db71>] _raw_spin_unlock_irqrestore+0x51/0x80
[117.005038] hardirqs last disabled at (2282669): [<ffffffff82882021>] sysvec_irq_work+0x11/0xc0
[117.005043] softirqs last enabled at (2254702): [<ffffffff8289fd00>] __do_softirq+0x10/0x18
[117.005047] softirqs last disabled at (2254725): [<ffffffff813d4ddf>] __irq_exit_rcu+0x13f/0x160
[117.005051] ---[ end trace 0000000000000000 ]---
Make the timer IRQ safe.
[1] https://patchwork.freedesktop.org/series/154987/#rev2
Fixes: 4077798484janusz.krzysztofik@linux.intel.com >
Reviewed-by: Christian König <christian.koenig@amd.com >
Link: https://lore.kernel.org/r/20250926152628.2165080-2-janusz.krzysztofik@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2026-01-11 15:21:12 +01:00
Guido Günther
2f97ed8e88
drm/panel: visionox-rm69299: Don't clear all mode flags
...
[ Upstream commit 39144b611e9cd4f5814f4098c891b545dd70c536 ]
Don't clear all mode flags. We only want to maek sure we use HS mode
during unprepare.
Fixes: c7f66d32ddneil.armstrong@linaro.org >
Signed-off-by: Guido Günther <agx@sigxcpu.org >
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com >
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org >
Link: https://lore.kernel.org/r/20250910-shift6mq-panel-v3-2-a7729911afb9@sigxcpu.org
Signed-off-by: Sasha Levin <sashal@kernel.org >
2026-01-11 15:21:11 +01:00
Mainak Sen
6245cce711
gpu: host1x: Fix race in syncpt alloc/free
...
[ Upstream commit c7d393267c497502fa737607f435f05dfe6e3d9b ]
Fix race condition between host1x_syncpt_alloc()
and host1x_syncpt_put() by using kref_put_mutex()
instead of kref_put() + manual mutex locking.
This ensures no thread can acquire the
syncpt_mutex after the refcount drops to zero
but before syncpt_release acquires it.
This prevents races where syncpoints could
be allocated while still being cleaned up
from a previous release.
Remove explicit mutex locking in syncpt_release
as kref_put_mutex() handles this atomically.
Signed-off-by: Mainak Sen <msen@nvidia.com >
Fixes: f5ba33fb96mperttunen@nvidia.com >
Signed-off-by: Thierry Reding <treding@nvidia.com >
Link: https://lore.kernel.org/r/20250707-host1x-syncpt-race-fix-v1-1-28b0776e70bc@nvidia.com
Signed-off-by: Sasha Levin <sashal@kernel.org >
2026-01-11 15:21:11 +01:00
