dri-devel January 2022

dri-devel@lists.freedesktop.org

373 participants
842 discussions

[PATCH] drm/amdgpu: Wrong order for config and counter_id parameters
by jinsdb＠126.com 27 Jan '22

27 Jan '22

From: huangqu <jinsdb(a)126.com> Wrong order for config and counter_id parameters was passed, when calling df_v3_6_pmc_set_deferred and df_v3_6_pmc_is_deferred functions. Signed-off-by: huangqu <jinsdb(a)126.com> --- drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/df_v3_6.c b/drivers/gpu/drm/amd/amdgpu/df_v3_6.c index 43c5e3ec9..f4dfca013 100644 --- a/drivers/gpu/drm/amd/amdgpu/df_v3_6.c +++ b/drivers/gpu/drm/amd/amdgpu/df_v3_6.c @@ -458,7 +458,7 @@ static int df_v3_6_pmc_add_cntr(struct amdgpu_device *adev, #define DEFERRED_ARM_MASK (1 << 31) static int df_v3_6_pmc_set_deferred(struct amdgpu_device *adev, - int counter_idx, uint64_t config, + uint64_t config, int counter_idx, bool is_deferred) { @@ -476,8 +476,8 @@ static int df_v3_6_pmc_set_deferred(struct amdgpu_device *adev, } static bool df_v3_6_pmc_is_deferred(struct amdgpu_device *adev, - int counter_idx, - uint64_t config) + uint64_t config, + int counter_idx) { return (df_v3_6_pmc_has_counter(adev, config, counter_idx) && (adev->df_perfmon_config_assign_mask[counter_idx] -- 2.31.1

2 1

[PATCH] drm/amd/amdgpu: fix spelling mistake "disbale" -> "disable"
by tangmeng 27 Jan '22

27 Jan '22

There is a spelling mistake. Fix it. Signed-off-by: tangmeng <tangmeng(a)uniontech.com> --- drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c index aef9d059ae52..a642c04cf17d 100644 --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c @@ -544,7 +544,7 @@ static int xgpu_vi_mailbox_rcv_irq(struct amdgpu_device *adev, { int r; - /* trigger gpu-reset by hypervisor only if TDR disbaled */ + /* trigger gpu-reset by hypervisor only if TDR disabled */ if (!amdgpu_gpu_recovery) { /* see what event we get */ r = xgpu_vi_mailbox_rcv_msg(adev, IDH_FLR_NOTIFICATION); -- 2.20.1

2 1

[PATCH] drm/msm: Remove spurious IRQF_ONESHOT flags from dsi & hdmi
by Daniel Thompson 27 Jan '22

27 Jan '22

Quoting the header comments, IRQF_ONESHOT is "Used by threaded interrupts which need to keep the irq line disabled until the threaded handler has been run.". When applied to an interrupt that doesn't request a threaded irq then IRQF_ONESHOT has a lesser known (undocumented?) side effect, which it to disable the forced threading of irqs (and for "normal" kernels it is a nop). In this case I can find no evidence that suppressing forced threading is intentional. Had it been intentional then a driver must adopt the raw_spinlock API in order to avoid deadlocks on PREEMPT_RT kernels (and avoid calling any kernel API that uses regular spinlocks). Fix this by removing the spurious additional flag. This change is required for my Snapdragon 7cx Gen2 tablet to boot-to-GUI with PREEMPT_RT enabled. Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> --- Notes: Just in case anybody asks, yes! I did use coccinelle to do a quick scan for similar issues. I didn't find any other instances in drivers/drm/ . drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +- drivers/gpu/drm/msm/hdmi/hdmi.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index 6b3ced4aaaf5d..3a3f53f0c8ae1 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -1877,7 +1877,7 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi) /* do not autoenable, will be enabled later */ ret = devm_request_irq(&pdev->dev, msm_host->irq, dsi_host_irq, - IRQF_TRIGGER_HIGH | IRQF_ONESHOT | IRQF_NO_AUTOEN, + IRQF_TRIGGER_HIGH | IRQF_NO_AUTOEN, "dsi_isr", msm_host); if (ret < 0) { dev_err(&pdev->dev, "failed to request IRQ%u: %d\n", diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c index 3acdeae25caf0..a1bfbc4c74bf7 100644 --- a/drivers/gpu/drm/msm/hdmi/hdmi.c +++ b/drivers/gpu/drm/msm/hdmi/hdmi.c @@ -301,7 +301,7 @@ int msm_hdmi_modeset_init(struct hdmi *hdmi, } ret = devm_request_irq(&pdev->dev, hdmi->irq, - msm_hdmi_irq, IRQF_TRIGGER_HIGH | IRQF_ONESHOT, + msm_hdmi_irq, IRQF_TRIGGER_HIGH, "hdmi_isr", hdmi); if (ret < 0) { DRM_DEV_ERROR(dev->dev, "failed to request IRQ%u: %d\n", base-commit: e783362eb54cd99b2cac8b3a9aeac942e6f6ac07 -- 2.34.1

2 1

[RFC][PATCH 00/10] drm: Add DRM module helpers for existing PCI drivers
by Thomas Zimmermann 27 Jan '22

27 Jan '22

This is an RFC patchset to complement the helper macros provided in [1]. The module helpers create module init and exit helpers that respect the kernel parameters that enable/disable DRM drivers. There's one more patch that prepares qxl by moving some code around. It's required to make use of the helpers from within qxl. Javier, please see if you find anything useful here and cherry-pick into your patchset. The driver changes should complement the ones in your patchset. The module macros are similar to yours and should be easily mergable. I tested the macros with ast. [1] https://patchwork.freedesktop.org/series/98162/ Thomas Zimmermann (10): drm: Provide PCI module-init macros drm/ast: Replace module-init boiler-plate code with DRM helpers drm/bochs: Replace module-init boiler-plate code with DRM helpers drm/cirrus: Replace module-init boiler-plate code with DRM helpers drm/hisilicon/hibmc: Replace module initialization with DRM helpers drm/mgag200: Replace module-init boiler-plate code with DRM helpers drm/qxl: Move ioctl array next to its only user drm/qxl: Replace module-init boiler-plate code with DRM helpers drm/vboxvideo: Replace module-init boiler-plate code with DRM helpers drm/vmwgfx: Replace module-init boiler-plate code with DRM helpers Documentation/gpu/drm-internals.rst | 6 ++ drivers/gpu/drm/ast/ast_drv.c | 18 +--- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 +- drivers/gpu/drm/mgag200/mgag200_drv.c | 20 +--- drivers/gpu/drm/qxl/qxl_drv.c | 31 +++--- drivers/gpu/drm/qxl/qxl_drv.h | 13 ++- drivers/gpu/drm/qxl/qxl_ioctl.c | 41 ++------ drivers/gpu/drm/tiny/bochs.c | 20 +--- drivers/gpu/drm/tiny/cirrus.c | 17 +--- drivers/gpu/drm/vboxvideo/vbox_drv.c | 20 +--- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 24 +---- include/drm/drm_module.h | 95 +++++++++++++++++++ 12 files changed, 145 insertions(+), 163 deletions(-) create mode 100644 include/drm/drm_module.h base-commit: 3f422828221d9ceefcddef0be33561b1646a1cbe -- 2.34.1

2 11

[PATCH v1] gpu: host1x: Fix hang on Tegra186+
by Dmitry Osipenko 27 Jan '22

27 Jan '22

Tegra186+ hangs if host1x hardware is disabled at a kernel boot time because we touch hardware before runtime PM is resumed. Move sync point assignment initialization to the RPM-resume callback. Older SoCs were unaffected because they skip that sync point initialization. Tested-by: Jon Hunter <jonathanh(a)nvidia.com> # T186 Reported-by: Jon Hunter <jonathanh(a)nvidia.com> # T186 Fixes: 6b6776e2ab8a ("gpu: host1x: Add initial runtime PM and OPP support") Signed-off-by: Dmitry Osipenko <digetx(a)gmail.com> --- drivers/gpu/host1x/syncpt.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c index e08e331e46ae..83a16e46146b 100644 --- a/drivers/gpu/host1x/syncpt.c +++ b/drivers/gpu/host1x/syncpt.c @@ -137,8 +137,15 @@ void host1x_syncpt_restore(struct host1x *host) struct host1x_syncpt *sp_base = host->syncpt; unsigned int i; - for (i = 0; i < host1x_syncpt_nb_pts(host); i++) + for (i = 0; i < host1x_syncpt_nb_pts(host); i++) { + /* + * Unassign syncpt from channels for purposes of Tegra186 + * syncpoint protection. This prevents any channel from + * accessing it until it is reassigned. + */ + host1x_hw_syncpt_assign_to_channel(host, sp_base + i, NULL); host1x_hw_syncpt_restore(host, sp_base + i); + } for (i = 0; i < host1x_syncpt_nb_bases(host); i++) host1x_hw_syncpt_restore_wait_base(host, sp_base + i); @@ -352,13 +359,6 @@ int host1x_syncpt_init(struct host1x *host) for (i = 0; i < host->info->nb_pts; i++) { syncpt[i].id = i; syncpt[i].host = host; - - /* - * Unassign syncpt from channels for purposes of Tegra186 - * syncpoint protection. This prevents any channel from - * accessing it until it is reassigned. - */ - host1x_hw_syncpt_assign_to_channel(host, &syncpt[i], NULL); } for (i = 0; i < host->info->nb_bases; i++) -- 2.33.1

2 1

[PATCH 0/2] drm/msm: Add tracking for faults associated with an address space
by Rob Clark 27 Jan '22

27 Jan '22

From: Rob Clark <robdclark(a)chromium.org> Currently, for GL_EXT_robustness userspace uses the global and per- submitqueue fault counters to determine GUILTY_CONTEXT_RESET_EXT vs INNOCENT_CONTEXT_RESET_EXT. But that is a bit overly paranoid, in that a fault in a different process's context (when it has it's own isolated address space) should not hurt anything. This is particularly annoying with CrOS and chrome's exit_on_context_lost quirk, while running deqp in the android container, as the deqp-egl suite has tests that intentionally trigger gpu hangs (for the purpose of testing the robustness extension), which triggers chrome to restart, which restarts the android container! This new param gives userspace a way to ignore faults triggered by other processes. Applies on top of https://patchwork.freedesktop.org/series/98907/ Rob Clark (2): drm/msm/gpu: Add ctx to get_param() drm/msm/gpu: Add param to get address space faults drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 +++++- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 ++- drivers/gpu/drm/msm/msm_drv.c | 4 +++- drivers/gpu/drm/msm/msm_gem.h | 3 +++ drivers/gpu/drm/msm/msm_gpu.c | 1 + drivers/gpu/drm/msm/msm_gpu.h | 3 ++- drivers/gpu/drm/msm/msm_rd.c | 6 ++++-- include/uapi/drm/msm_drm.h | 3 ++- 8 files changed, 22 insertions(+), 7 deletions(-) -- 2.34.1

1 2

[syzbot] inconsistent lock state in sync_info_debugfs_show
by syzbot 27 Jan '22

27 Jan '22

Hello, syzbot found the following issue on: HEAD commit: 1c52283265a4 Merge branch 'akpm' (patches from Andrew) git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1224663fb00000 kernel config: https://syzkaller.appspot.com/x/.config?x=75bc179af0ff0457 dashboard link: https://syzkaller.appspot.com/bug?extid=007bfe0f3330f6e1e7d1 compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+007bfe0f3330f6e1e7d1(a)syzkaller.appspotmail.com ================================ WARNING: inconsistent lock state 5.16.0-syzkaller #0 Not tainted -------------------------------- inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. syz-executor.2/18360 [HC0[0]:SC0[0]:HE0:SE1] takes: ffffffff8c712cf8 (sync_timeline_list_lock){?...}-{2:2}, at: spin_lock_irq include/linux/spinlock.h:374 [inline] ffffffff8c712cf8 (sync_timeline_list_lock){?...}-{2:2}, at: sync_info_debugfs_show+0x2d/0x200 drivers/dma-buf/sync_debug.c:147 {IN-HARDIRQ-W} state was registered at: lock_acquire kernel/locking/lockdep.c:5639 [inline] lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5604 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162 sync_timeline_debug_remove+0x25/0x190 drivers/dma-buf/sync_debug.c:31 sync_timeline_free drivers/dma-buf/sw_sync.c:104 [inline] kref_put include/linux/kref.h:65 [inline] sync_timeline_put drivers/dma-buf/sw_sync.c:116 [inline] timeline_fence_release+0x263/0x340 drivers/dma-buf/sw_sync.c:144 dma_fence_release+0x2ee/0x590 drivers/dma-buf/dma-fence.c:549 kref_put include/linux/kref.h:65 [inline] dma_fence_put include/linux/dma-fence.h:276 [inline] dma_fence_array_release+0x1e4/0x2b0 drivers/dma-buf/dma-fence-array.c:120 dma_fence_release+0x2ee/0x590 drivers/dma-buf/dma-fence.c:549 kref_put include/linux/kref.h:65 [inline] dma_fence_put include/linux/dma-fence.h:276 [inline] irq_dma_fence_array_work+0xa5/0xd0 drivers/dma-buf/dma-fence-array.c:52 irq_work_single+0x120/0x270 kernel/irq_work.c:211 irq_work_run_list+0x91/0xc0 kernel/irq_work.c:242 irq_work_run+0x54/0xd0 kernel/irq_work.c:251 __sysvec_irq_work+0x95/0x3d0 arch/x86/kernel/irq_work.c:22 sysvec_irq_work+0x8e/0xc0 arch/x86/kernel/irq_work.c:17 asm_sysvec_irq_work+0x12/0x20 arch/x86/include/asm/idtentry.h:664 __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:160 [inline] _raw_spin_unlock_irq+0x25/0x40 kernel/locking/spinlock.c:202 spin_unlock_irq include/linux/spinlock.h:399 [inline] sw_sync_debugfs_release+0x160/0x240 drivers/dma-buf/sw_sync.c:321 __fput+0x286/0x9f0 fs/file_table.c:311 task_work_run+0xdd/0x1a0 kernel/task_work.c:164 exit_task_work include/linux/task_work.h:32 [inline] do_exit+0xb29/0x2a30 kernel/exit.c:806 do_group_exit+0xd2/0x2f0 kernel/exit.c:935 get_signal+0x4b0/0x28c0 kernel/signal.c:2862 arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868 handle_signal_work kernel/entry/common.c:148 [inline] exit_to_user_mode_loop kernel/entry/common.c:172 [inline] exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207 __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300 ret_from_fork+0x15/0x30 arch/x86/entry/entry_64.S:288 irq event stamp: 124 hardirqs last enabled at (123): [<ffffffff894fd980>] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (123): [<ffffffff894fd980>] _raw_spin_unlock_irqrestore+0x50/0x70 kernel/locking/spinlock.c:194 hardirqs last disabled at (124): [<ffffffff894fd6e1>] __raw_spin_lock_irq include/linux/spinlock_api_smp.h:117 [inline] hardirqs last disabled at (124): [<ffffffff894fd6e1>] _raw_spin_lock_irq+0x41/0x50 kernel/locking/spinlock.c:170 softirqs last enabled at (116): [<ffffffff81465513>] invoke_softirq kernel/softirq.c:432 [inline] softirqs last enabled at (116): [<ffffffff81465513>] __irq_exit_rcu+0x123/0x180 kernel/softirq.c:637 softirqs last disabled at (97): [<ffffffff81465513>] invoke_softirq kernel/softirq.c:432 [inline] softirqs last disabled at (97): [<ffffffff81465513>] __irq_exit_rcu+0x123/0x180 kernel/softirq.c:637 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(sync_timeline_list_lock); <Interrupt> lock(sync_timeline_list_lock); *** DEADLOCK *** 3 locks held by syz-executor.2/18360: #0: ffff88801e30c0f0 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:1034 #1: ffff88807a26dd58 (&p->lock){+.+.}-{3:3}, at: seq_read_iter+0xdf/0x1280 fs/seq_file.c:182 #2: ffffffff8c712cf8 (sync_timeline_list_lock){?...}-{2:2}, at: spin_lock_irq include/linux/spinlock.h:374 [inline] #2: ffffffff8c712cf8 (sync_timeline_list_lock){?...}-{2:2}, at: sync_info_debugfs_show+0x2d/0x200 drivers/dma-buf/sync_debug.c:147 stack backtrace: CPU: 0 PID: 18360 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_usage_bug kernel/locking/lockdep.c:203 [inline] valid_state kernel/locking/lockdep.c:3945 [inline] mark_lock_irq kernel/locking/lockdep.c:4148 [inline] mark_lock.cold+0x61/0x8e kernel/locking/lockdep.c:4605 mark_held_locks+0x9f/0xe0 kernel/locking/lockdep.c:4206 __trace_hardirqs_on_caller kernel/locking/lockdep.c:4224 [inline] lockdep_hardirqs_on_prepare kernel/locking/lockdep.c:4292 [inline] lockdep_hardirqs_on_prepare+0x135/0x400 kernel/locking/lockdep.c:4244 trace_hardirqs_on+0x5b/0x1c0 kernel/trace/trace_preemptirq.c:49 __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline] _raw_spin_unlock_irq+0x1f/0x40 kernel/locking/spinlock.c:202 spin_unlock_irq include/linux/spinlock.h:399 [inline] sync_print_obj drivers/dma-buf/sync_debug.c:118 [inline] sync_info_debugfs_show+0xeb/0x200 drivers/dma-buf/sync_debug.c:153 seq_read_iter+0x4f5/0x1280 fs/seq_file.c:230 seq_read+0x3e8/0x5c0 fs/seq_file.c:162 vfs_read+0x1b5/0x600 fs/read_write.c:479 ksys_read+0x12d/0x250 fs/read_write.c:619 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f781fb4b059 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f781e4c0168 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007f781fc5df60 RCX: 00007f781fb4b059 RDX: 0000000000000008 RSI: 0000000020000140 RDI: 0000000000000003 RBP: 00007f781fba508d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fff0ff6575f R14: 00007f781e4c0300 R15: 0000000000022000 </TASK> --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

1 0

[PATCH] drm/panel: simple: Initialize bpc in RK101II01D-CT panel descriptor
by Rahul T R 27 Jan '22

27 Jan '22

Initialize bpc while creating panel_desc structure for RK101II01D-CT Below warning is triggered since bpc is not being initialized WARNING: CPU: 2 PID: 47 at drivers/gpu/drm/panel/panel-simple.c:614 panel_simple_probe+0x1b0/0x3c8 Signed-off-by: Rahul T R <r-ravikumar(a)ti.com> --- drivers/gpu/drm/panel/panel-simple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index dde033066f3d..32f775db5cb7 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -3027,6 +3027,7 @@ static const struct drm_display_mode rocktech_rk101ii01d_ct_mode = { static const struct panel_desc rocktech_rk101ii01d_ct = { .modes = &rocktech_rk101ii01d_ct_mode, + .bpc = 8, .num_modes = 1, .size = { .width = 217, -- 2.17.1

1 3

[PATCH v2] drm/mediatek: mtk_dsi: Avoid EPROBE_DEFER loop with external bridge
by AngeloGioacchino Del Regno 27 Jan '22

27 Jan '22

DRM bridge drivers are now attaching their DSI device at probe time, which requires us to register our DSI host in order to let the bridge to probe: this recently started producing an endless -EPROBE_DEFER loop on some machines that are using external bridges, like the parade-ps8640, found on the ACER Chromebook R13. Now that the DSI hosts/devices probe sequence is documented, we can do adjustments to the mtk_dsi driver as to both fix now and make sure to avoid this situation in the future: for this, following what is documented in drm_bridge.c, move the mtk_dsi component_add() to the mtk_dsi_ops.attach callback and delete it in the detach callback; keeping in mind that we are registering a drm_bridge for our DSI, which is only used/attached if the DSI Host is bound, it wouldn't make sense to keep adding our bridge at probe time (as it would be useless to have it if mtk_dsi_ops.attach() fails!), so also move that one to the dsi host attach function (and remove it in detach). Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Reviewed-by: Andrzej Hajda <andrzej.hajda(a)intel.com> --- drivers/gpu/drm/mediatek/mtk_dsi.c | 167 +++++++++++++++-------------- 1 file changed, 84 insertions(+), 83 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c index 5d90d2eb0019..bced4c7d668e 100644 --- a/drivers/gpu/drm/mediatek/mtk_dsi.c +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c @@ -786,18 +786,101 @@ void mtk_dsi_ddp_stop(struct device *dev) mtk_dsi_poweroff(dsi); } +static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi) +{ + int ret; + + ret = drm_simple_encoder_init(drm, &dsi->encoder, + DRM_MODE_ENCODER_DSI); + if (ret) { + DRM_ERROR("Failed to encoder init to drm\n"); + return ret; + } + + dsi->encoder.possible_crtcs = mtk_drm_find_possible_crtc_by_comp(drm, dsi->host.dev); + + ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, + DRM_BRIDGE_ATTACH_NO_CONNECTOR); + if (ret) + goto err_cleanup_encoder; + + dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder); + if (IS_ERR(dsi->connector)) { + DRM_ERROR("Unable to create bridge connector\n"); + ret = PTR_ERR(dsi->connector); + goto err_cleanup_encoder; + } + drm_connector_attach_encoder(dsi->connector, &dsi->encoder); + + return 0; + +err_cleanup_encoder: + drm_encoder_cleanup(&dsi->encoder); + return ret; +} + +static int mtk_dsi_bind(struct device *dev, struct device *master, void *data) +{ + int ret; + struct drm_device *drm = data; + struct mtk_dsi *dsi = dev_get_drvdata(dev); + + ret = mtk_dsi_encoder_init(drm, dsi); + if (ret) + return ret; + + return device_reset_optional(dev); +} + +static void mtk_dsi_unbind(struct device *dev, struct device *master, + void *data) +{ + struct mtk_dsi *dsi = dev_get_drvdata(dev); + + drm_encoder_cleanup(&dsi->encoder); +} + +static const struct component_ops mtk_dsi_component_ops = { + .bind = mtk_dsi_bind, + .unbind = mtk_dsi_unbind, +}; + static int mtk_dsi_host_attach(struct mipi_dsi_host *host, struct mipi_dsi_device *device) { struct mtk_dsi *dsi = host_to_dsi(host); + struct device *dev = host->dev; + int ret; dsi->lanes = device->lanes; dsi->format = device->format; dsi->mode_flags = device->mode_flags; + dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0); + if (IS_ERR(dsi->next_bridge)) + return PTR_ERR(dsi->next_bridge); + + drm_bridge_add(&dsi->bridge); + + ret = component_add(host->dev, &mtk_dsi_component_ops); + if (ret) { + DRM_ERROR("failed to add dsi_host component: %d\n", ret); + drm_bridge_remove(&dsi->bridge); + return ret; + } return 0; } +static int mtk_dsi_host_detach(struct mipi_dsi_host *host, + struct mipi_dsi_device *device) +{ + struct mtk_dsi *dsi = host_to_dsi(host); + + component_del(host->dev, &mtk_dsi_component_ops); + drm_bridge_remove(&dsi->bridge); + return 0; +} + static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi) { int ret; @@ -938,73 +1021,14 @@ static ssize_t mtk_dsi_host_transfer(struct mipi_dsi_host *host, static const struct mipi_dsi_host_ops mtk_dsi_ops = { .attach = mtk_dsi_host_attach, + .detach = mtk_dsi_host_detach, .transfer = mtk_dsi_host_transfer, }; -static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi) -{ - int ret; - - ret = drm_simple_encoder_init(drm, &dsi->encoder, - DRM_MODE_ENCODER_DSI); - if (ret) { - DRM_ERROR("Failed to encoder init to drm\n"); - return ret; - } - - dsi->encoder.possible_crtcs = mtk_drm_find_possible_crtc_by_comp(drm, dsi->host.dev); - - ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, - DRM_BRIDGE_ATTACH_NO_CONNECTOR); - if (ret) - goto err_cleanup_encoder; - - dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder); - if (IS_ERR(dsi->connector)) { - DRM_ERROR("Unable to create bridge connector\n"); - ret = PTR_ERR(dsi->connector); - goto err_cleanup_encoder; - } - drm_connector_attach_encoder(dsi->connector, &dsi->encoder); - - return 0; - -err_cleanup_encoder: - drm_encoder_cleanup(&dsi->encoder); - return ret; -} - -static int mtk_dsi_bind(struct device *dev, struct device *master, void *data) -{ - int ret; - struct drm_device *drm = data; - struct mtk_dsi *dsi = dev_get_drvdata(dev); - - ret = mtk_dsi_encoder_init(drm, dsi); - if (ret) - return ret; - - return device_reset_optional(dev); -} - -static void mtk_dsi_unbind(struct device *dev, struct device *master, - void *data) -{ - struct mtk_dsi *dsi = dev_get_drvdata(dev); - - drm_encoder_cleanup(&dsi->encoder); -} - -static const struct component_ops mtk_dsi_component_ops = { - .bind = mtk_dsi_bind, - .unbind = mtk_dsi_unbind, -}; - static int mtk_dsi_probe(struct platform_device *pdev) { struct mtk_dsi *dsi; struct device *dev = &pdev->dev; - struct drm_panel *panel; struct resource *regs; int irq_num; int ret; @@ -1021,19 +1045,6 @@ static int mtk_dsi_probe(struct platform_device *pdev) return ret; } - ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0, - &panel, &dsi->next_bridge); - if (ret) - goto err_unregister_host; - - if (panel) { - dsi->next_bridge = devm_drm_panel_bridge_add(dev, panel); - if (IS_ERR(dsi->next_bridge)) { - ret = PTR_ERR(dsi->next_bridge); - goto err_unregister_host; - } - } - dsi->driver_data = of_device_get_match_data(dev); dsi->engine_clk = devm_clk_get(dev, "engine"); @@ -1098,14 +1109,6 @@ static int mtk_dsi_probe(struct platform_device *pdev) dsi->bridge.of_node = dev->of_node; dsi->bridge.type = DRM_MODE_CONNECTOR_DSI; - drm_bridge_add(&dsi->bridge); - - ret = component_add(&pdev->dev, &mtk_dsi_component_ops); - if (ret) { - dev_err(&pdev->dev, "failed to add component: %d\n", ret); - goto err_unregister_host; - } - return 0; err_unregister_host: @@ -1118,8 +1121,6 @@ static int mtk_dsi_remove(struct platform_device *pdev) struct mtk_dsi *dsi = platform_get_drvdata(pdev); mtk_output_dsi_disable(dsi); - drm_bridge_remove(&dsi->bridge); - component_del(&pdev->dev, &mtk_dsi_component_ops); mipi_dsi_host_unregister(&dsi->host); return 0; -- 2.33.1

4 5

Re: [PATCH] misc: fastrpc: avoid double fput() on failed usercopy
by Greg Kroah-Hartman 27 Jan '22

27 Jan '22

On Thu, Jan 27, 2022 at 02:24:29PM +0100, Greg Kroah-Hartman wrote: > On Thu, Jan 27, 2022 at 02:02:18PM +0100, Mathias Krause wrote: > > If the copy back to userland fails for the FASTRPC_IOCTL_ALLOC_DMA_BUFF > > ioctl(), we shouldn't assume that 'buf->dmabuf' is still valid. In fact, > > dma_buf_fd() called fd_install() before, i.e. "consumed" one reference, > > leaving us with none. > > > > Calling dma_buf_put() will therefore put a reference we no longer own, > > leading to a valid file descritor table entry for an already released > > 'file' object which is a straight use-after-free. > > > > Simply avoid calling dma_buf_put() and rely on the process exit code to > > do the necessary cleanup, if needed, i.e. if the file descriptor is > > still valid. > > > > Fixes: 6cffd79504ce ("misc: fastrpc: Add support for dmabuf exporter") > > Signed-off-by: Mathias Krause <minipli(a)grsecurity.net> > > --- > > drivers/misc/fastrpc.c | 9 ++++++++- > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c > > index 4ccbf43e6bfa..aa1682b94a23 100644 > > --- a/drivers/misc/fastrpc.c > > +++ b/drivers/misc/fastrpc.c > > @@ -1288,7 +1288,14 @@ static int fastrpc_dmabuf_alloc(struct fastrpc_user *fl, char __user *argp) > > } > > > > if (copy_to_user(argp, &bp, sizeof(bp))) { > > - dma_buf_put(buf->dmabuf); > > + /* > > + * The usercopy failed, but we can't do much about it, as > > + * dma_buf_fd() already called fd_install() and made the > > + * file descriptor accessible for the current process. It > > + * might already be closed and dmabuf no longer valid when > > + * we reach this point. Therefore "leak" the fd and rely on > > + * the process exit path to do any required cleanup. > > + */ > > return -EFAULT; > > } > > > > This feels wrong. How do all other dma buf users handle this? > > And you forgot to cc: the dmabuf developers, I think get_maintainers.pl > should have caught them on this patch. Odd, it didn't, not your fault, my apologies. DMA BUFFER maintainers, what happened to the MAINTAINERS regex that caused the above patch to not catch you all? thanks, greg k-h

2 1

← Newer
1
...
23
24
25
26
27
28
29
...
85
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2022