- Dec 09, 2024
-
-
Frieder Schrempf authored🤖 Sync Bot: Update v6.12-ktn to Latest Stable Kernel (v6.12.4) See merge request !176 -
Frieder Schrempf authored
PMIC PCA9450 LDO5 Fixes (SD card voltage selection) See merge request !170
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20241206143527.654980698@linuxfoundation.org Tested-by:
Ronald Warsow <rwarsow@gmx.de> Tested-by:
Luna Jernberg <droidbittin@gmail.com> Tested-by:
Mark Brown <broonie@kernel.org> Tested-by:
Salvatore Bonaccorso <carnil@debian.org> Tested-by:
Florian Fainelli <florian.fainelli@broadcom.com> Tested-by:
Peter Schneider <pschneider1968@googlemail.com> Tested-by:
Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by:
Ron Economos <re@w6rz.net> Tested-by:
kernelci.org bot <bot@kernelci.org> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ashutosh Dixit authored
commit 0191fddf53748cf2b473d78faeabe6dcb47689d2 upstream. This reverts commit 55858fa7eb2f163f7aa34339fd3399ba4ff564c6. '55858fa7eb2f ("drm/xe/xe_guc_ads: save/restore OA registers and allowlist regs")' was not properly reviewed and also causes dmesg asserts in CI. Revert it. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3295 Fixes: 55858fa7eb2f ("drm/xe/xe_guc_ads: save/restore OA registers and allowlist regs") Signed-off-by:Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241029200147.1476513-1-ashutosh.dixit@intel.com Signed-off-by:
-
Frederic Weisbecker authored
commit 63dffecfba3eddcf67a8f76d80e0c141f93d44a5 upstream. A sigqueue belonging to a posix timer, which target is not a specific thread but a whole thread group, is preferrably targeted to the current task if it is part of that thread group. However nothing prevents a posix timer event from queueing such a sigqueue from a reaped yet running task. The interruptible code space between exit_notify() and the final call to schedule() is enough for posix_timer_fn() hrtimer to fire. If that happens while the current task is part of the thread group target, it is proposed to handle it but since its sighand pointer may have been cleared already, the sigqueue is dropped even if there are other tasks running within the group that could handle it. As a result posix timers with thread group wide target may miss signals when some of their threads are exiting. Fix this with verifying that the current task hasn't been through exit_notify() before proposing it as a preferred target so as to ensure that its sighand is still here and stable. complete_signal() might still reconsider the choice and find a better target within the group if current has passed retarget_shared_pending() already. Fixes: bcb7ee79 ("posix-timers: Prefer delivery of signals to the current thread") Reported-by:
Anthony Mallet <anthony.mallet@laas.fr> Suggested-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Frederic Weisbecker <frederic@kernel.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
-
Ovidiu Bunea authored
commit a3e6079bd93d5c66a43bf6a5f90e5b98465dc7b3 upstream. There are cases where an OTG is remapped from driving a regular HDMI display to a DP/eDP display. There are also cases where DTBCLK needs to be enabled for HPO, but DTBCLK DTO programming may be done while OTG is still enabled which is dangerous as the PIPE_DTO_SRC_SEL programming may change the pixel clock generator source for a mapped and running OTG and cause it to hang. Remove the PIPE_DTO_SRC_SEL programming from this sequence since it is already done in program_pixel_clk(). Additionally, make sure that program_pixel_clk sets DTBCLK DTO as source for special HDMI cases. Cc: stable@vger.kernel.org # 6.11+ Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
Ovidiu Bunea <Ovidiu.Bunea@amd.com> Signed-off-by:
Hamza Mahfooz <hamza.mahfooz@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Yihan Zhu authored
commit 8fef253c94a5312b9150b2ff8e633b331bac7e88 upstream. [Why] No check on head pipe during the dml to dc hw mapping will allow illegal pipe usage. This will result in a wrong pipe topology to cause mpcc tree totally mess up then cause a display hang. [How] Avoid to use the pipe is head in all check and avoid ODM slice during preferred pipe check. Cc: stable@vger.kernel.org Reviewed-by:
Yihan Zhu <Yihan.Zhu@amd.com> Signed-off-by:
-
Joshua Aberback authored
commit 27227a234c1487cb7a684615f0749c455218833a upstream. [Why] The mechanism to backup and restore plane states doesn't maintain refcount, which can cause issues if the refcount of the plane changes in between backup and restore operations, such as memory leaks if the refcount was supposed to go down, or double frees / invalid memory accesses if the refcount was supposed to go up. [How] Cache and re-apply current refcount when restoring plane states. Cc: stable@vger.kernel.org Reviewed-by:
Josip Pavic <josip.pavic@amd.com> Signed-off-by:
Joshua Aberback <joshua.aberback@amd.com> Signed-off-by:
-
Lijo Lazar authored
commit da868898cf4c5ddbd1f7406e356edce5d7211eb5 upstream. As per power team, there is no need to impose a lower bound on arcturus power limit. Any unreasonable limit set will result in frequent throttling. Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Reviewed-by:
Kenneth Feng <kenneth.feng@amd.com> Signed-off-by:
-
Kenneth Feng authored
commit b0df0e777874549c128b43f7bf4989a2ed24b37a upstream. disable pcie speed switching on Intel platform for smu v14.0.2/3 based on Intel's requirement. v2: align the setting with smu v13. Signed-off-by:
-
Umio Yasuno authored
commit 2abf2f7032df4c4e7f6cf7906da59d0e614897d6 upstream. These were missed before. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3751 Signed-off-by:
Umio Yasuno <coelacanth_dream@protonmail.com> Signed-off-by:
-
Mario Limonciello authored
commit 349af06a3abd0bb3787ee2daf3ac508412fe8dcc upstream. There is a strapping issue on NBIO 7.11.x that can lead to spurious PME events while in the D0 state. Cc: stable@vger.kernel.org Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
-
Kenneth Feng authored
commit 76c7f08094767b5df3b60e18d1bdecddd4a5c844 upstream. skip setting power source on smu v14.0.2/3 Signed-off-by:
-
Vitaly Prosyak authored
commit b61badd20b443eabe132314669bb51a263982e5c upstream. [ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147 [ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1 [ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000016] Call Trace: [ +0.000008] <TASK> [ +0.000009] dump_stack_lvl+0x76/0xa0 [ +0.000017] print_report+0xce/0x5f0 [ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] ? srso_return_thunk+0x5/0x5f [ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200 [ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] kasan_report+0xbe/0x110 [ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000023] __asan_report_load8_noabort+0x14/0x30 [ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_write+0x14/0x30 [ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? enable_work+0x124/0x220 [ +0.000015] ? __pfx_enable_work+0x10/0x10 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? free_large_kmalloc+0x85/0xf0 [ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched] [ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu] [ +0.000735] ? __kasan_check_read+0x11/0x20 [ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu] [ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu] [ +0.000679] ? mutex_unlock+0x80/0xe0 [ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu] [ +0.000662] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? mutex_unlock+0x80/0xe0 [ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu] [ +0.000663] drm_minor_release+0xc9/0x140 [drm] [ +0.000081] drm_release+0x1fd/0x390 [drm] [ +0.000082] __fput+0x36c/0xad0 [ +0.000018] __fput_sync+0x3c/0x50 [ +0.000014] __x64_sys_close+0x7d/0xe0 [ +0.000014] x64_sys_call+0x1bc6/0x2680 [ +0.000014] do_syscall_64+0x70/0x130 [ +0.000014] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190 [ +0.000015] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit+0x43/0x50 [ +0.000012] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? exc_page_fault+0x7c/0x110 [ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000014] RIP: 0033:0x7ffff7b14f67 [ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff [ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67 [ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003 [ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000 [ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8 [ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040 [ +0.000020] </TASK> [ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s: [ +0.000014] kasan_save_stack+0x28/0x60 [ +0.000008] kasan_save_track+0x18/0x70 [ +0.000007] kasan_save_alloc_info+0x38/0x60 [ +0.000007] __kasan_kmalloc+0xc1/0xd0 [ +0.000007] kmalloc_trace_noprof+0x180/0x380 [ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched] [ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu] [ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu] [ +0.000662] amdgpu_pci_probe+0x361/0xf30 [amdgpu] [ +0.000651] local_pci_probe+0xe7/0x1b0 [ +0.000009] pci_device_probe+0x248/0x890 [ +0.000008] really_probe+0x1fd/0x950 [ +0.000008] __driver_probe_device+0x307/0x410 [ +0.000007] driver_probe_device+0x4e/0x150 [ +0.000007] __driver_attach+0x223/0x510 [ +0.000006] bus_for_each_dev+0x102/0x1a0 [ +0.000007] driver_attach+0x3d/0x60 [ +0.000006] bus_add_driver+0x2ac/0x5f0 [ +0.000006] driver_register+0x13d/0x490 [ +0.000008] __pci_register_driver+0x1ee/0x2b0 [ +0.000007] llc_sap_close+0xb0/0x160 [llc] [ +0.000009] do_one_initcall+0x9c/0x3e0 [ +0.000008] do_init_module+0x241/0x760 [ +0.000008] load_module+0x51ac/0x6c30 [ +0.000006] __do_sys_init_module+0x234/0x270 [ +0.000007] __x64_sys_init_module+0x73/0xc0 [ +0.000006] x64_sys_call+0xe3/0x2680 [ +0.000006] do_syscall_64+0x70/0x130 [ +0.000007] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000015] Freed by task 2147 on cpu 6 at 160.507651s: [ +0.000013] kasan_save_stack+0x28/0x60 [ +0.000007] kasan_save_track+0x18/0x70 [ +0.000007] kasan_save_free_info+0x3b/0x60 [ +0.000007] poison_slab_object+0x115/0x1c0 [ +0.000007] __kasan_slab_free+0x34/0x60 [ +0.000007] kfree+0xfa/0x2f0 [ +0.000007] drm_sched_fini+0x19d/0x410 [gpu_sched] [ +0.000012] amdgpu_fence_driver_sw_fini+0xc4/0x2f0 [amdgpu] [ +0.000662] amdgpu_device_fini_sw+0x77/0xfc0 [amdgpu] [ +0.000653] amdgpu_driver_release_kms+0x16/0x80 [amdgpu] [ +0.000655] drm_minor_release+0xc9/0x140 [drm] [ +0.000071] drm_release+0x1fd/0x390 [drm] [ +0.000071] __fput+0x36c/0xad0 [ +0.000008] __fput_sync+0x3c/0x50 [ +0.000007] __x64_sys_close+0x7d/0xe0 [ +0.000007] x64_sys_call+0x1bc6/0x2680 [ +0.000007] do_syscall_64+0x70/0x130 [ +0.000007] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000014] The buggy address belongs to the object at ffff8881b8605f80 which belongs to the cache kmalloc-64 of size 64 [ +0.000020] The buggy address is located 8 bytes inside of freed 64-byte region [ffff8881b8605f80, ffff8881b8605fc0) [ +0.000028] The buggy address belongs to the physical page: [ +0.000011] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1b8605 [ +0.000008] anon flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) [ +0.000007] page_type: 0xffffefff(slab) [ +0.000009] raw: 0017ffffc0000000 ffff8881000428c0 0000000000000000 dead000000000001 [ +0.000006] raw: 0000000000000000 0000000000200020 00000001ffffefff 0000000000000000 [ +0.000006] page dumped because: kasan: bad access detected [ +0.000012] Memory state around the buggy address: [ +0.000011] ffff8881b8605e80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ +0.000015] ffff8881b8605f00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc [ +0.000015] >ffff8881b8605f80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ +0.000013] ^ [ +0.000011] ffff8881b8606000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc [ +0.000014] ffff8881b8606080: fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb fb [ +0.000013] ================================================================== The issue reproduced on VG20 during the IGT pci_unplug test. The root cause of the issue is that the function drm_sched_fini is called before drm_sched_entity_kill. In drm_sched_fini, the drm_sched_rq structure is freed, but this structure is later accessed by each entity within the run queue, leading to invalid memory access. To resolve this, the order of cleanup calls is updated: Before: amdgpu_fence_driver_sw_fini amdgpu_device_ip_fini After: amdgpu_device_ip_fini amdgpu_fence_driver_sw_fini This updated order ensures that all entities in the IPs are cleaned up first, followed by proper cleanup of the schedulers. Additional Investigation: During debugging, another issue was identified in the amdgpu_vce_sw_fini function. The vce.vcpu_bo buffer must be freed only as the final step in the cleanup process to prevent any premature access during earlier cleanup stages. v2: Using Christian suggestion call drm_sched_entity_destroy before drm_sched_fini. Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:Vitaly Prosyak <vitaly.prosyak@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Mario Limonciello authored
commit 902fbbf429b8213232b18de0ddfd5c0f3851cb8f upstream. Earlier ASICs have strap information exported, and this is missing for NBIO 7.11.0. Cc: stable@vger.kernel.org Reviewed-by:
-
Kenneth Feng authored
commit 6719ab8234ce4b0c0e9aa93aaa94961e5b2bc852 upstream. add gen5 display to the user on smu v14.0.2/3 Signed-off-by:
Yang Wang <kevinyang.wang@amd.com> Signed-off-by:
-
Lijo Lazar authored
commit cdc6705f98ea3f854a60ba8c9b19228e197ae384 upstream. Write pointer could be 32-bit or 64-bit. Use the correct size during initialization. Signed-off-by:
-
Matthew Auld authored
commit 87651f31ae4e6e6e7e6c7270b9b469405e747407 upstream. Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3371 Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241122161914.321263-6-matthew.auld@intel.com (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e) Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
-
Matthew Auld authored
commit c78f4399188369a55eed69cbf19a8aad2a65ac75 upstream. On some HW we want to avoid the host caching PTEs, since access from GPU side can be incoherent. However here the special migrate object is mapping PTEs which are written from the host and potentially cached. Use XE_BO_FLAG_PAGETABLE to ensure that non-cached mapping is used, on platforms where this matters. Fixes: 7a060d78 ("drm/xe/mtl: Map PPGTT as CPU:WC") Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
-
Alex Deucher authored
commit 979bfe291b5b30a9132c2fd433247e677b24c6aa upstream. This reverts commit 949658cb. This causes a blank screen on boot. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3696 Signed-off-by:
-
Matthew Auld authored
commit 23346f85163de83aca6dc30dde3944131cf54706 upstream. XE_CACHE_WB must be converted into the per-platform pat index for that particular caching mode, otherwise we are just encoding whatever happens to be the value of that enum. Fixes: e8babb28 ("drm/xe: Convert multiple bind ops into single job") Signed-off-by:
-
Jonathan Cavitt authored
commit 55858fa7eb2f163f7aa34339fd3399ba4ff564c6 upstream. Several OA registers and allowlist registers were missing from the save/restore list for GuC and could be lost during an engine reset. Add them to the list. v2: - Fix commit message (Umesh) - Add missing closes (Ashutosh) v3: - Add missing fixes (Ashutosh) Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2249 Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Suggested-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Suggested-by:
John Harrison <john.c.harrison@intel.com> Signed-off-by:
-
Steffen Dirkwinkel authored
commit 71ba1c9b1c717831920c3d432404ee5a707e04b4 upstream. drm_kms_helper_poll_init needs to be called after zynqmp_dpsub_kms_init. zynqmp_dpsub_kms_init creates the connector and without it we don't enable hotplug detection. Fixes: eb2d64bf ("drm: xlnx: zynqmp_dpsub: Report HPD through the bridge") Cc: stable@vger.kernel.org Signed-off-by:
Steffen Dirkwinkel <s.dirkwinkel@beckhoff.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241028134218.54727-1-lists@steffen.cc Signed-off-by:
-
Lucas Stach authored
commit 4f8dbadef085ab447a01a8d4806a3f629fea05ed upstream. The shader L1 cache is a writeback cache for shader loads/stores and thus must be flushed before any BOs backing the shader buffers are potentially freed. Cc: stable@vger.kernel.org Reviewed-by:
Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
Chen-Yu Tsai authored
commit c5f3f21728b069412e8072b8b1d0a3d9d3ab0265 upstream. The IT6505 bridge chip has a active low reset line. Since it is a "reset" and not an "enable" line, the GPIO should be asserted to put it in reset and deasserted to bring it out of reset during the power on sequence. The polarity was inverted when the driver was first introduced, likely because the device family that was targeted had an inverting level shifter on the reset line. The MT8186 Corsola devices already have the IT6505 in their device tree, but the whole display pipeline is actually disabled and won't be enabled until some remaining issues are sorted out. The other known user is the MT8183 Kukui / Jacuzzi family; their device trees currently do not have the IT6505 included. Fix the polarity in the driver while there are no actual users. Fixes: b5c84a9e ("drm/bridge: add it6505 driver") Cc: stable@vger.kernel.org Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241029095411.657616-1-wenst@chromium.org Signed-off-by:
Chen-Yu Tsai <wenst@chromium.org> Signed-off-by:
-
Javier Carrasco authored
commit f708e8b4cfd16e5c8cd8d7fcfcb2fb2c6ed93af3 upstream. Early exits (goto, break, return) from for_each_child_of_node() required an explicit call to of_node_put(), which was not introduced with the break if cnt == MAX_CRTC. Add the missing of_node_put() before the break. Cc: stable@vger.kernel.org Fixes: d761b945 ("drm/mediatek: Add cnt checking for coverity issue") Signed-off-by:
Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by:
CK Hu <ck.hu@mediatek.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20241011-mtk_drm_drv_memleak-v1-1-2b40c74c8d75@gmail.com/ Signed-off-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by:
-
Thomas Zimmermann authored
commit 67c40c9b2ec5f375bf78274d4e9ef0e3b8315bea upstream. Commit 808a40b6 ("drm/fbdev-dma: Implement damage handling and deferred I/O") added deferred I/O for fbdev-dma. Also select the Kconfig symbol FB_DEFERRED_IO (via FB_DMAMEM_HELPERS_DEFERRED). Fixes build errors about missing fbdefio, such as drivers/gpu/drm/drm_fbdev_dma.c:218:26: error: 'struct drm_fb_helper' has no member named 'fbdefio' 218 | fb_helper->fbdefio.delay = HZ / 20; | ^~ drivers/gpu/drm/drm_fbdev_dma.c:219:26: error: 'struct drm_fb_helper' has no member named 'fbdefio' 219 | fb_helper->fbdefio.deferred_io = drm_fb_helper_deferred_io; | ^~ drivers/gpu/drm/drm_fbdev_dma.c:221:21: error: 'struct fb_info' has no member named 'fbdefio' 221 | info->fbdefio = &fb_helper->fbdefio; | ^~ drivers/gpu/drm/drm_fbdev_dma.c:221:43: error: 'struct drm_fb_helper' has no member named 'fbdefio' 221 | info->fbdefio = &fb_helper->fbdefio; | ^~ Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202410050241.Mox9QRjP-lkp@intel.com/ Fixes: 808a40b6 ("drm/fbdev-dma: Implement damage handling and deferred I/O") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: <stable@vger.kernel.org> # v6.11+ Reviewed-by:
-
Ma Ke authored
commit 831214f77037de02afc287eae93ce97f218d8c04 upstream. The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure. Cc: stable@vger.kernel.org Fixes: dd86dc2f ("drm/sti: implement atomic_check for the planes") Signed-off-by:
Ma Ke <make24@iscas.ac.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20240913090412.2022848-1-make24@iscas.ac.cn Signed-off-by:
Alain Volmat <alain.volmat@foss.st.com> Signed-off-by:
-
Hugo Villeneuve authored
commit 66ae275365be4f118abe2254a0ced1d913af93f2 upstream. Now that the driver has been converted to use wrapped MIPI DCS functions, the num_init_cmds structure member is no longer needed, so remove it. Fixes: 35583e12 ("drm/panel: panel-jadard-jd9365da-h3: use wrapped MIPI DCS functions") Cc: stable@vger.kernel.org Signed-off-by:
Hugo Villeneuve <hvilleneuve@dimonoff.com> Reviewed-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Link: https://lore.kernel.org/r/20240930170503.1324560-1-hugo@hugovil.com Signed-off-by:
-
Ma Ke authored
commit e965e771b069421c233d674c3c8cd8c7f7245f42 upstream. The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure. Cc: stable@vger.kernel.org Fixes: dd86dc2f ("drm/sti: implement atomic_check for the planes") Signed-off-by:
-
Ma Ke authored
commit c1ab40a1fdfee732c7e6ff2fb8253760293e47e8 upstream. The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure. Cc: stable@vger.kernel.org Fixes: dd86dc2f ("drm/sti: implement atomic_check for the planes") Signed-off-by:
-
Lyude Paul authored
commit 319e53f155907cf2c6dabc16ec9dce0179bc04d1 upstream. It turns out that if you happen to have a kernel config where CONFIG_DRM_PANIC is disabled and spinlock debugging is enabled, along with KMS being enabled - we'll end up trying to acquire an uninitialized spin_lock with drm_panic_lock() when we try to do a commit: rvkms rvkms.0: [drm:drm_atomic_commit] committing 0000000068d2ade1 INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 4 PID: 1347 Comm: modprobe Not tainted 6.10.0-rc1Lyude-Test+ #272 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20240524-3.fc40 05/24/2024 Call Trace: <TASK> dump_stack_lvl+0x77/0xa0 assign_lock_key+0x114/0x120 register_lock_class+0xa8/0x2c0 __lock_acquire+0x7d/0x2bd0 ? __vmap_pages_range_noflush+0x3a8/0x550 ? drm_atomic_helper_swap_state+0x2ad/0x3a0 lock_acquire+0xec/0x290 ? drm_atomic_helper_swap_state+0x2ad/0x3a0 ? lock_release+0xee/0x310 _raw_spin_lock_irqsave+0x4e/0x70 ? drm_atomic_helper_swap_state+0x2ad/0x3a0 drm_atomic_helper_swap_state+0x2ad/0x3a0 drm_atomic_helper_commit+0xb1/0x270 drm_atomic_commit+0xaf/0xe0 ? __pfx___drm_printfn_info+0x10/0x10 drm_client_modeset_commit_atomic+0x1a1/0x250 drm_client_modeset_commit_locked+0x4b/0x180 drm_client_modeset_commit+0x27/0x50 __drm_fb_helper_restore_fbdev_mode_unlocked+0x76/0x90 drm_fb_helper_set_par+0x38/0x40 fbcon_init+0x3c4/0x690 visual_init+0xc0/0x120 do_bind_con_driver+0x409/0x4c0 do_take_over_console+0x233/0x280 do_fb_registered+0x11f/0x210 fbcon_fb_registered+0x2c/0x60 register_framebuffer+0x248/0x2a0 __drm_fb_helper_initial_config_and_unlock+0x58a/0x720 drm_fbdev_generic_client_hotplug+0x6e/0xb0 drm_client_register+0x76/0xc0 _RNvXs_CsHeezP08sTT_5rvkmsNtB4_5RvkmsNtNtCs1cdwasc6FUb_6kernel8platform6Driver5probe+0xed2/0x1060 [rvkms] ? _RNvMs_NtCs1cdwasc6FUb_6kernel8platformINtB4_7AdapterNtCsHeezP08sTT_5rvkms5RvkmsE14probe_callbackBQ_+0x2b/0x70 [rvkms] ? acpi_dev_pm_attach+0x25/0x110 ? platform_probe+0x6a/0xa0 ? really_probe+0x10b/0x400 ? __driver_probe_device+0x7c/0x140 ? driver_probe_device+0x22/0x1b0 ? __device_attach_driver+0x13a/0x1c0 ? __pfx___device_attach_driver+0x10/0x10 ? bus_for_each_drv+0x114/0x170 ? __device_attach+0xd6/0x1b0 ? bus_probe_device+0x9e/0x120 ? device_add+0x288/0x4b0 ? platform_device_add+0x75/0x230 ? platform_device_register_full+0x141/0x180 ? rust_helper_platform_device_register_simple+0x85/0xb0 ? _RNvMs2_NtCs1cdwasc6FUb_6kernel8platformNtB5_6Device13create_simple+0x1d/0x60 ? _RNvXs0_CsHeezP08sTT_5rvkmsNtB5_5RvkmsNtCs1cdwasc6FUb_6kernel6Module4init+0x11e/0x160 [rvkms] ? 0xffffffffc083f000 ? init_module+0x20/0x1000 [rvkms] ? kernfs_xattr_get+0x3e/0x80 ? do_one_initcall+0x148/0x3f0 ? __lock_acquire+0x5ef/0x2bd0 ? __lock_acquire+0x5ef/0x2bd0 ? __lock_acquire+0x5ef/0x2bd0 ? put_cpu_partial+0x51/0x1d0 ? lock_acquire+0xec/0x290 ? put_cpu_partial+0x51/0x1d0 ? lock_release+0xee/0x310 ? put_cpu_partial+0x51/0x1d0 ? fs_reclaim_acquire+0x69/0xf0 ? lock_acquire+0xec/0x290 ? fs_reclaim_acquire+0x69/0xf0 ? kfree+0x22f/0x340 ? lock_release+0xee/0x310 ? kmalloc_trace_noprof+0x48/0x340 ? do_init_module+0x22/0x240 ? kmalloc_trace_noprof+0x155/0x340 ? do_init_module+0x60/0x240 ? __se_sys_finit_module+0x2e0/0x3f0 ? do_syscall_64+0xa4/0x180 ? syscall_exit_to_user_mode+0x108/0x140 ? do_syscall_64+0xb0/0x180 ? vma_end_read+0xd0/0xe0 ? do_user_addr_fault+0x309/0x640 ? clear_bhb_loop+0x45/0xa0 ? clear_bhb_loop+0x45/0xa0 ? clear_bhb_loop+0x45/0xa0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> Fix this by stubbing these macros out when this config option isn't enabled, along with fixing the unused variable warning that introduces. Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: e2a1cda3 ("drm/panic: Add drm panic locking") Cc: <stable@vger.kernel.org> # v6.10+ Link: https://patchwork.freedesktop.org/patch/msgid/20240916230103.611490-1-lyude@redhat.com Signed-off-by:
-
Francesco Dolcini authored
commit 566c2d83887f0570056833102adc5b88e681b0c7 upstream. Depending on the SoC where the FEC is integrated into the PPS channel might be routed to different timer instances. Make this configurable from the devicetree. When the related DT property is not present fallback to the previous default and use channel 0. Reviewed-by:
Frank Li <Frank.Li@nxp.com> Tested-by:
Rafael Beims <rafael.beims@toradex.com> Signed-off-by:
Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by:
Csókás, Bence <csokas.bence@prolan.hu> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Francesco Dolcini authored
commit bf8ca67e21671e7a56e31da45360480b28f185f1 upstream. Preparation patch to allow for PPS channel configuration, no functional change intended. Signed-off-by:
-
Francesco Dolcini authored
commit 1aa772be0444a2bd06957f6d31865e80e6ae4244 upstream. Add fsl,pps-channel property to select where to connect the PPS signal. This depends on the internal SoC routing and on the board, for example on the i.MX8 SoC it can be connected to an external pin (using channel 1) or to internal eDMA as DMA request (channel 0). Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Carlos Llamas authored
commit cb2aeb2ec25884133110ffe5a67ff3cf7dee5ceb upstream. Add the pending proc->delivered_freeze work to the debugfs output. This information was omitted in the original implementation of the freeze notification and can be valuable for debugging issues. Fixes: d579b04a ("binder: frozen notification") Cc: stable@vger.kernel.org Signed-off-by:
Carlos Llamas <cmllamas@google.com> Acked-by:
Todd Kjos <tkjos@google.com> Reviewed-by:
Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240926233632.821189-9-cmllamas@google.com Signed-off-by:
-
Carlos Llamas authored
commit 1db76ec2b4b206ff943e292a0b55e68ff3443598 upstream. If a freeze notification is cleared with BC_CLEAR_FREEZE_NOTIFICATION before calling binder_freeze_notification_done(), then it is detached from its reference (e.g. ref->freeze) but the work remains queued in proc->delivered_freeze. This leads to a memory leak when the process exits as any pending entries in proc->delivered_freeze are not freed: unreferenced object 0xffff38e8cfa36180 (size 64): comm "binder-util", pid 655, jiffies 4294936641 hex dump (first 32 bytes): b8 e9 9e c8 e8 38 ff ff b8 e9 9e c8 e8 38 ff ff .....8.......8.. 0b 00 00 00 00 00 00 00 3c 1f 4b 00 00 00 00 00 ........<.K..... backtrace (crc 95983b32): [<000000000d0582cf>] kmemleak_alloc+0x34/0x40 [<000000009c99a513>] __kmalloc_cache_noprof+0x208/0x280 [<00000000313b1704>] binder_thread_write+0xdec/0x439c [<000000000cbd33bb>] binder_ioctl+0x1b68/0x22cc [<000000002bbedeeb>] __arm64_sys_ioctl+0x124/0x190 [<00000000b439adee>] invoke_syscall+0x6c/0x254 [<00000000173558fc>] el0_svc_common.constprop.0+0xac/0x230 [<0000000084f72311>] do_el0_svc+0x40/0x58 [<000000008b872457>] el0_svc+0x38/0x78 [<00000000ee778653>] el0t_64_sync_handler+0x120/0x12c [<00000000a8ec61bf>] el0t_64_sync+0x190/0x194 This patch fixes the leak by ensuring that any pending entries in proc->delivered_freeze are freed during binder_deferred_release(). Fixes: d579b04a ("binder: frozen notification") Cc: stable@vger.kernel.org Signed-off-by: -
Carlos Llamas authored
commit ca63c66935b978441055e3d87d30225267f99329 upstream. Alice points out that binder_request_freeze_notification() should not return EINVAL when the relevant node is dead [1]. The node can die at any point even if the user input is valid. Instead, allow the request to be allocated but skip the initial notification for dead nodes. This avoids propagating unnecessary errors back to userspace. Fixes: d579b04a ("binder: frozen notification") Cc: stable@vger.kernel.org Suggested-by:
-
Carlos Llamas authored
commit 595ea72efff9fa65bc52b6406e0822f90841f266 upstream. proc 699 context binder-test thread 699: l 00 need_return 0 tr 0 ref 25: desc 1 node 20 s 1 w 0 d 00000000c03e09a3 unknown work: type 11 proc 640 context binder-test thread 640: l 00 need_return 0 tr 0 ref 8: desc 1 node 3 s 1 w 0 d 000000002bb493e1 has cleared freeze notification Fixes: d579b04a ("binder: frozen notification") Cc: stable@vger.kernel.org Suggested-by:
-
Carlos Llamas authored
commit 830d7db744b42c693bf1db7e94db86d7efd91f0e upstream. The BINDER_WORK_FROZEN_BINDER type is not handled in the binder_logs entries and it shows up as "unknown work" when logged: proc 649 context binder-test thread 649: l 00 need_return 0 tr 0 ref 13: desc 1 node 8 s 1 w 0 d 0000000053c4c0c3 unknown work: type 10 This patch add the freeze work type and is now logged as such: proc 637 context binder-test thread 637: l 00 need_return 0 tr 0 ref 8: desc 1 node 3 s 1 w 0 d 00000000dc39e9c6 has frozen binder Fixes: d579b04a ("binder: frozen notification") Cc: stable@vger.kernel.org Acked-by:
-
