dri-devel August 2019

dri-devel@lists.freedesktop.org

318 participants
2338 discussions

[PATCH] drm/virtio: kick vq outside of the vq lock
by Chia-I Wu 02 Aug '19

02 Aug '19

Replace virtqueue_kick by virtqueue_kick_prepare, which requires serialization, and virtqueue_notify, which does not. Repurpose the return values to indicate whether the vq should be notified. This fixes a lock contention with qemu host. When the guest calls vibad rtqueue_notify, the qemu vcpu thread exits the guest and waits for the qemu iothread to perform the MMIO. If the qemu iothread is still processing the prior buffer, and if the prior buffer is cheap to GPU, the iothread will go ahead and generate an IRQ for the guest. A worker thread in the guest will call virtio_gpu_dequeue_ctrl_func. If virtqueue_notify was called with the vq lock held, the worker thread would busy wait inside virtio_gpu_dequeue_ctrl_func. Signed-off-by: Chia-I Wu <olvaffe(a)gmail.com> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index 6c1a90717535..e96f88fe5c83 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -291,11 +291,9 @@ static int virtio_gpu_queue_ctrl_buffer_locked(struct virtio_gpu_device *vgdev, trace_virtio_gpu_cmd_queue(vq, (struct virtio_gpu_ctrl_hdr *)vbuf->buf); - virtqueue_kick(vq); + ret = virtqueue_kick_prepare(vq); } - if (!ret) - ret = vq->num_free; return ret; } @@ -307,6 +305,10 @@ static int virtio_gpu_queue_ctrl_buffer(struct virtio_gpu_device *vgdev, spin_lock(&vgdev->ctrlq.qlock); rc = virtio_gpu_queue_ctrl_buffer_locked(vgdev, vbuf); spin_unlock(&vgdev->ctrlq.qlock); + + if (rc > 0) + virtqueue_notify(vgdev->ctrlq.vq); + return rc; } @@ -339,6 +341,10 @@ static int virtio_gpu_queue_fenced_ctrl_buffer(struct virtio_gpu_device *vgdev, virtio_gpu_fence_emit(vgdev, hdr, fence); rc = virtio_gpu_queue_ctrl_buffer_locked(vgdev, vbuf); spin_unlock(&vgdev->ctrlq.qlock); + + if (rc > 0) + virtqueue_notify(vgdev->ctrlq.vq); + return rc; } @@ -369,13 +375,14 @@ static int virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev, trace_virtio_gpu_cmd_queue(vq, (struct virtio_gpu_ctrl_hdr *)vbuf->buf); - virtqueue_kick(vq); + ret = virtqueue_kick_prepare(vq); } spin_unlock(&vgdev->cursorq.qlock); - if (!ret) - ret = vq->num_free; + if (ret > 0) + virtqueue_notify(vq); + return ret; } -- 2.22.0.410.gd8fdbe21b5-goog

2 2

[PATCH] drm/komeda: Initialize and enable output polling on Komeda
by Lowry Li (Arm Technology China) 02 Aug '19

02 Aug '19

From: "Lowry Li (Arm Technology China)" <Lowry.Li(a)arm.com> Initialize and enable output polling on Komeda. Changes since v1: 1. Enable the polling before registering the driver; 2. Disable the polling after unregistering the driver. Signed-off-by: Lowry Li (Arm Technology China) <lowry.li(a)arm.com> --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c index 419a8b0..25716a30 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c @@ -15,6 +15,7 @@ #include <drm/drm_gem_framebuffer_helper.h> #include <drm/drm_irq.h> #include <drm/drm_vblank.h> +#include <drm/drm_probe_helper.h> #include "komeda_dev.h" #include "komeda_framebuffer.h" @@ -315,6 +316,8 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev) drm->irq_enabled = true; + drm_kms_helper_poll_init(drm); + err = drm_dev_register(drm, 0); if (err) goto cleanup_mode_config; @@ -338,6 +341,7 @@ void komeda_kms_detach(struct komeda_kms_dev *kms) drm->irq_enabled = false; mdev->funcs->disable_irq(mdev); drm_dev_unregister(drm); + drm_kms_helper_poll_fini(drm); component_unbind_all(mdev->dev, drm); komeda_kms_cleanup_private_objs(kms); drm_mode_config_cleanup(drm); -- 1.9.1

1 0

[Bug 111281] When the s admin try to create different types of question in various difficulty level by single upload mode database error occurred
by bugzilla-daemon＠freedesktop.org 02 Aug '19

02 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=111281 Bug ID: 111281 Summary: When the s admin try to create different types of question in various difficulty level by single upload mode database error occurred Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: critical Priority: medium Component: General Assignee: dri-devel(a)lists.freedesktop.org Reporter: dhrisyasby93(a)gmail.com Test step: 1.Launch mozilla firefox 2.type URL:http://westkutt-testnew.targetentrance.com/login 3.Login with the Email: sadmin(a)oqbs.com and password:admin click on sign in Click on question bank click on add New Questions Click on Single choice MCQs Enter Question Title Enter description Select Subject Select Chapter Select difficulty level Enter options Enter explanation Click on publish Click on approve Click on preview Click on submit -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 111283] pending questions can not be downloaded by s admin,privileged admin,privileged examiner
by bugzilla-daemon＠freedesktop.org 02 Aug '19

02 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=111283 Bug ID: 111283 Summary: pending questions can not be downloaded by s admin,privileged admin,privileged examiner Product: DRI Version: unspecified Hardware: Other OS: Windows (All) Status: NEW Severity: minor Priority: medium Component: General Assignee: dri-devel(a)lists.freedesktop.org Reporter: dhrisyasby93(a)gmail.com Test step: " 1"".Launch mozilla firefox 2.type URL :http://http://testwestkutt.targetentrance.com/logi 3.Login with the Email: sadmin(a)oqbs.com and password:admin"" rrejeena100(a)gmail.com and password:diamondshunter rrejeena001(a)gmail.com and password:rejeenai click on sign in Click on question bank Click on download questions Select question type Select subject Select chapter Select Question catagory Click on download Click on ok -- You are receiving this mail because: You are the assignee for the bug.

1 1

Re: Threaded submission & semaphore sharing
by Koenig, Christian 02 Aug '19

02 Aug '19

Am 02.08.2019 07:17 schrieb Lionel Landwerlin <lionel.g.landwerlin(a)intel.com>: On 02/08/2019 08:08, Koenig, Christian wrote: Hi Lionel, Well that looks more like your test case is buggy. According to the code the ctx1 queue always waits for sem1 and ctx2 queue always waits for sem2. That's supposed to be the same underlying syncobj because it's exported from one VkDevice as opaque FD from sem1 and imported into sem2. Well than that's still buggy and won't synchronize at all. When ctx1 waits for a semaphore and then signals the same semaphore there is no guarantee that ctx2 will run in between jobs. It's perfectly valid in this case to first run all jobs from ctx1 and then all jobs from ctx2. It only prevents running both at the same time and as far as I can see that still works even with threaded submission. You need at least two semaphores for a tandem submission. Regards, Christian. This way there can't be any Synchronisation between the two. Regards, Christian. Am 02.08.2019 06:55 schrieb Lionel Landwerlin <lionel.g.landwerlin(a)intel.com><mailto:lionel.g.landwerlin@intel.com>: Hey Christian, The problem boils down to the fact that we don't immediately create dma fences when calling vkQueueSubmit(). This is delayed to a thread. From a single application thread, you can QueueSubmit() to 2 queues from 2 different devices. Each QueueSubmit to one queue has a dependency on the previous QueueSubmit on the other queue through an exported/imported semaphore. From the API point of view the state of the semaphore should be changed after each QueueSubmit(). The problem is that it's not because of the thread and because you might have those 2 submission threads tied to different VkDevice/VkInstance or even different applications (synchronizing themselves outside the vulkan API). Hope that makes sense. It's not really easy to explain by mail, the best explanation is probably reading the test : https://gitlab.freedesktop.org/mesa/crucible/blob/master/src/tests/func/syn… Like David mentioned you're not running into that issue right now, because you only dispatch to the thread under specific conditions. But I could build a case to force that and likely run into the same issue. -Lionel On 02/08/2019 07:33, Koenig, Christian wrote: Hi Lionel, Well could you describe once more what the problem is? Cause I don't fully understand why a rather normal tandem submission with two semaphores should fail in any way. Regards, Christian. Am 02.08.2019 06:28 schrieb Lionel Landwerlin <lionel.g.landwerlin(a)intel.com><mailto:lionel.g.landwerlin@intel.com>: There aren't CTS tests covering the issue I was mentioning. But we could add them. I don't have all the details regarding your implementation but even with the "semaphore thread", I could see it running into the same issues. What if a mix of binary & timeline semaphores are handed to vkQueueSubmit()? For example with queueA & queueB from 2 different VkDevice : vkQueueSubmit(queueA, signal semA); vkQueueSubmit(queueA, wait on [semA, timelineSemB]); with timelineSemB triggering a wait before signal. vkQueueSubmit(queueB, signal semA); -Lionel On 02/08/2019 06:18, Zhou, David(ChunMing) wrote: > Hi Lionel, > > By the Queue thread is a heavy thread, which is always resident in driver during application running, our guys don't like that. So we switch to Semaphore Thread, only when waitBeforeSignal of timeline happens, we spawn a thread to handle that wait. So we don't have your this issue. > By the way, I already pass all your CTS cases for now. I suggest you to switch to Semaphore Thread instead of Queue Thread as well. It works very well. > > -David > > -----Original Message----- > From: Lionel Landwerlin <lionel.g.landwerlin(a)intel.com><mailto:lionel.g.landwerlin@intel.com> > Sent: Friday, August 2, 2019 4:52 AM > To: dri-devel <dri-devel(a)lists.freedesktop.org><mailto:dri-devel@lists.freedesktop.org>; Koenig, Christian <Christian.Koenig(a)amd.com><mailto:Christian.Koenig@amd.com>; Zhou, David(ChunMing) <David1.Zhou(a)amd.com><mailto:David1.Zhou@amd.com>; Jason Ekstrand <jason(a)jlekstrand.net><mailto:jason@jlekstrand.net> > Subject: Threaded submission & semaphore sharing > > Hi Christian, David, > > Sorry to report this so late in the process, but I think we found an issue not directly related to syncobj timelines themselves but with a side effect of the threaded submissions. > > Essentially we're failing a test in crucible : > func.sync.semaphore-fd.opaque-fd > This test create a single binary semaphore, shares it between 2 VkDevice/VkQueue. > Then in a loop it proceeds to submit workload alternating between the 2 VkQueue with one submit depending on the other. > It does so by waiting on the VkSemaphore signaled in the previous iteration and resignaling it. > > The problem for us is that once things are dispatched to the submission thread, the ordering of the submission is lost. > Because we have 2 devices and they both have their own submission thread. > > Jason suggested that we reestablish the ordering by having semaphores/syncobjs carry an additional uint64_t payload. > This 64bit integer would represent be an identifier that submission threads will WAIT_FOR_AVAILABLE on. > > The scenario would look like this : > - vkQueueSubmit(queueA, signal on semA); > - in the caller thread, this would increment the syncobj additional u64 payload and return it to userspace. > - at some point the submission thread of queueA submits the workload and signal the syncobj of semA with value returned in the caller thread of vkQueueSubmit(). > - vkQueueSubmit(queueB, wait on semA); > - in the caller thread, this would read the syncobj additional > u64 payload > - at some point the submission thread of queueB will try to submit the work, but first it will WAIT_FOR_AVAILABLE the u64 value returned in the step above > > Because we want the binary semaphores to be shared across processes and would like this to remain a single FD, the simplest location to store this additional u64 payload would be the DRM syncobj. > It would need an additional ioctl to read & increment the value. > > What do you think? > > -Lionel

2 1

[linux-next] mm/i915: i915_gemfs_init() NULL dereference
by Sergey Senozhatsky 02 Aug '19

02 Aug '19

Hi, My laptop oopses early on with nothing on the screen; after some debugging I managed to obtain a backtrace: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 0 P4D 0 Oops: 0010 [#1] PREEMPT SMP PTI RIP: 0010:0x0 Code: Bad RIP value. [..] Call Trace: i915_gemfs_init+0x6e/0xa0 [i915] i915_gem_init_early+0x76/0x90 [i915] i915_driver_probe+0x30a/0x1640 [i915] ? kernfs_activate+0x5a/0x80 ? kernfs_add_one+0xdd/0x130 pci_device_probe+0x9e/0x110 really_probe+0xce/0x230 driver_probe_device+0x4b/0xc0 device_driver_attach+0x4e/0x60 __driver_attach+0x47/0xb0 ? device_driver_attach+0x60/0x60 bus_for_each_dev+0x61/0x90 bus_add_driver+0x167/0x1b0 driver_register+0x67/0xaa ? 0xffffffffc0522000 do_one_initcall+0x37/0x13f ? kmem_cache_alloc+0x11a/0x150 do_init_module+0x51/0x200 __se_sys_init_module+0xef/0x100 do_syscall_64+0x49/0x250 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP is at 0x00, which is never good It sort of boils down to commit 144df3b288c4 (vfs: Convert ramfs, shmem, tmpfs, devtmpfs, rootfs to use the new mount API), which removed ->remount_fs from tmpfs' ops: === @@ -3736,7 +3849,6 @@ static const struct super_operations shmem_ops = { .destroy_inode = shmem_destroy_inode, #ifdef CONFIG_TMPFS .statfs = shmem_statfs, - .remount_fs = shmem_remount_fs, .show_options = shmem_show_options, #endif .evict_inode = shmem_evict_inode, === So i915 init executes NULL get_fs_type("tmpfs"); sb->s_op->remount_fs(sb, &flags, options); For the time being the following (obvious and wrong) patch at least boots -next: --- diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c b/drivers/gpu/drm/i915/gem/i915_gemfs.c index 099f3397aada..1f95d9ea319a 100644 --- a/drivers/gpu/drm/i915/gem/i915_gemfs.c +++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c @@ -39,6 +39,9 @@ int i915_gemfs_init(struct drm_i915_private *i915) int flags = 0; int err; + if (!sb->s_op->remount_fs) + return -ENODEV; + err = sb->s_op->remount_fs(sb, &flags, options); if (err) { kern_unmount(gemfs); --- -ss

3 3

Threaded submission & semaphore sharing
by Lionel Landwerlin 02 Aug '19

02 Aug '19

Hi Christian, David, Sorry to report this so late in the process, but I think we found an issue not directly related to syncobj timelines themselves but with a side effect of the threaded submissions. Essentially we're failing a test in crucible : func.sync.semaphore-fd.opaque-fd This test create a single binary semaphore, shares it between 2 VkDevice/VkQueue. Then in a loop it proceeds to submit workload alternating between the 2 VkQueue with one submit depending on the other. It does so by waiting on the VkSemaphore signaled in the previous iteration and resignaling it. The problem for us is that once things are dispatched to the submission thread, the ordering of the submission is lost. Because we have 2 devices and they both have their own submission thread. Jason suggested that we reestablish the ordering by having semaphores/syncobjs carry an additional uint64_t payload. This 64bit integer would represent be an identifier that submission threads will WAIT_FOR_AVAILABLE on. The scenario would look like this : - vkQueueSubmit(queueA, signal on semA); - in the caller thread, this would increment the syncobj additional u64 payload and return it to userspace. - at some point the submission thread of queueA submits the workload and signal the syncobj of semA with value returned in the caller thread of vkQueueSubmit(). - vkQueueSubmit(queueB, wait on semA); - in the caller thread, this would read the syncobj additional u64 payload - at some point the submission thread of queueB will try to submit the work, but first it will WAIT_FOR_AVAILABLE the u64 value returned in the step above Because we want the binary semaphores to be shared across processes and would like this to remain a single FD, the simplest location to store this additional u64 payload would be the DRM syncobj. It would need an additional ioctl to read & increment the value. What do you think? -Lionel

3 6

[Bug 111282] When the s admin try to create different types of question in various difficulty level by bulk mode multiple answer accepted in single choice and t/f.And in multiple choice single answer also accepted.
by bugzilla-daemon＠freedesktop.org 02 Aug '19

02 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=111282 Bug ID: 111282 Summary: When the s admin try to create different types of question in various difficulty level by bulk mode multiple answer accepted in single choice and t/f.And in multiple choice single answer also accepted. Product: DRI Version: unspecified Hardware: All OS: Windows (All) Status: NEW Severity: major Priority: medium Component: General Assignee: dri-devel(a)lists.freedesktop.org Reporter: dhrisyasby93(a)gmail.com Test step: 1.Launch mozilla firefox 2.type URL:http://westkutt-testnew.targetentrance.com/login 3.Login with the Email: sadmin(a)oqbs.com and password:admin click on sign in Click on question bank Click on Bulk upload Select File type Click on T/F Enter Question Title Select Subject Select Chapter Select difficulty level Enter options Enter explanation click on save file Select File Input Click on approve Click on publish Click on upload -- You are receiving this mail because: You are the assignee for the bug.

1 2

drm fixes for 5.3-rc3
by Dave Airlie 02 Aug '19

02 Aug '19

Hi Linus, Thanks to Daniel for handling the email the last couple of weeks, flus and break-ins combined to derail me. Surprised nothing materialised today to take me out again. I've also tried embedding the summary into the signed pull request, since all the cool kids seemed to be doing it, it's a bit messy in my workflow as I do most of my stuff remotely including signing, but I usually edit the summary locally. Otherwise, just more amdgpu navi fixes, msm fixes and a single nouveau regression fix. Thanks, Dave. drm-fixes-2019-08-02: drm pull fixes for 5.3-rc3 amdgpu: navi10 temperature and pstate fixes vcn dynamic power management fix CS ioctl error handling fix debugfs info leak fix amdkfd VegaM fix. msm: dma sync call fix mdp5 dsi command mode fix fall-through fixes disabled GPU fix nouveau: regression fix for displayport MST support. The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b: Linux 5.3-rc2 (2019-07-28 12:47:02 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-08-02 for you to fetch changes up to f8981e0309e9004c6e86d218049045700c79d740: Merge tag 'msm-fixes-2019_08_01' of https://gitlab.freedesktop.org/drm/msm into drm-fixes (2019-08-02 10:17:25 +1000) ---------------------------------------------------------------- drm pull fixes for 5.3-rc3 amdgpu: navi10 temperature and pstate fixes vcn dynamic power management fix CS ioctl error handling fix debugfs info leak fix amdkfd VegaM fix. msm: dma sync call fix mdp5 dsi command mode fix fall-through fixes disabled GPU fix nouveau: regression fix for displayport MST support. ---------------------------------------------------------------- Alex Deucher (1): drm/amdgpu/powerplay: use proper revision id for navi Brian Masney (1): drm/msm: add support for per-CRTC max_vblank_count on mdp5 Christian König (1): drm/amdgpu: fix error handling in amdgpu_cs_process_fence_dep Dave Airlie (2): Merge tag 'drm-fixes-5.3-2019-07-31' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'msm-fixes-2019_08_01' of https://gitlab.freedesktop.org/drm/msm into drm-fixes Evan Quan (7): drm/amd/powerplay: fix null pointer dereference around dpm state relates drm/amd/powerplay: enable SW SMU reset functionality drm/amd/powerplay: add new sensor type for VCN powergate status drm/amd/powerplay: support VCN powergate status retrieval on Raven drm/amd/powerplay: support VCN powergate status retrieval for SW SMU drm/amd/powerplay: correct Navi10 VCN powergate control (v2) drm/amd/powerplay: correct UVD/VCE/VCN power status retrieval Jeffrey Hugo (1): drm: msm: Fix add_gpu_components Jordan Crouse (1): drm/msm: Annotate intentional switch statement fall throughs Kent Russell (1): drm/amdkfd: Fix byte align on VegaM Kevin Wang (2): drm/amd/powerplay: add callback function of get_thermal_temperature_range drm/amd/powerplay: fix temperature granularity error in smu11 Lyude Paul (1): drm/nouveau: Only release VCPI slots on mode changes Rob Clark (1): drm/msm: Use the correct dma_sync calls in msm_gem Wang Xiayang (1): drm/amdgpu: fix a potential information leaking bug drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 26 ++++---- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 74 +++++++++++++++-------- drivers/gpu/drm/amd/include/kgd_pp_interface.h | 1 + drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 23 ++++--- drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 9 +++ drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 1 - drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 48 +++++++++------ drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 36 ++++++----- drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 34 ++++------- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 + drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 1 + drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 + drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 16 ++++- drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +- drivers/gpu/drm/msm/msm_drv.c | 3 +- drivers/gpu/drm/msm/msm_gem.c | 47 ++++++++++++-- drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- 19 files changed, 215 insertions(+), 116 deletions(-)

1 0

[PATCH][drm-next] drm/amd/powerplay: fix off-by-one upper bounds limit checks
by Colin King 02 Aug '19

02 Aug '19

From: Colin Ian King <colin.king(a)canonical.com> There are two occurrances of off-by-one upper bound checking of indexes causing potential out-of-bounds array reads. Fix these. Addresses-Coverity: ("Out-of-bounds read") Fixes: cb33363d0e85 ("drm/amd/powerplay: add smu feature name support") Fixes: 6b294793e384 ("drm/amd/powerplay: add smu message name support") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c index d029a99e600e..b64113740eb5 100644 --- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c +++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c @@ -38,7 +38,7 @@ static const char* __smu_message_names[] = { const char *smu_get_message_name(struct smu_context *smu, enum smu_message_type type) { - if (type < 0 || type > SMU_MSG_MAX_COUNT) + if (type < 0 || type >= SMU_MSG_MAX_COUNT) return "unknown smu message"; return __smu_message_names[type]; } @@ -51,7 +51,7 @@ static const char* __smu_feature_names[] = { const char *smu_get_feature_name(struct smu_context *smu, enum smu_feature_mask feature) { - if (feature < 0 || feature > SMU_FEATURE_COUNT) + if (feature < 0 || feature >= SMU_FEATURE_COUNT) return "unknown smu feature"; return __smu_feature_names[feature]; } -- 2.20.1

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2019