Fix the memory overrun issue caused by wrong array size.
Signed-off-by: Ma Jun
Reported-by: coverity-bot
Addresses-Coverity-ID: 1527133 ("Memory - corruptions")
Fixes: 624693863 ("drm/amdkfd: Fix the warning of
array-index-out-of-bounds")
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
1
Thanks, I will send the fix patch.
Regards,
Ma Jun
On 11/5/2022 4:40 AM, Felix Kuehling wrote:
> On 2022-11-04 15:41, coverity-bot wrote:
>> Hello!
>>
>> This is an experimental semi-automated report about issues detected by
>> Coverity from a scan of next-20221104 as part of the linux-next scan
change guarantees that gfxoff is allowed before moving further in
s2idle sequence to add more reliablity about gfxoff in amdgpu IP's
suspend flow
Signed-off-by: Harsh Jain
---
v2: replaced flush_work with direct call to amdgpu_dpm_set_powergating_by_smu
and edited title
---
diff --git a/driver
Starting from SIENNA CICHLID asic supports two gfx pipes, enabling
two graphics queues for performance concern.
v2: Don't change the entity number of AMDGPU_HW_IP_GFX
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 42 +-
1 file changed, 21 inserti
Move TMR region from top of FB to 2MB for FFBM, so we need to reserve TMR region
firstly to make sure TMR can be allocated at 2MB
Signed-off-by: Tong Liu01
---
.../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 106 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 51 +
d
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: Ma, Jun
Sent: Monday, November 7, 2022 10:56 AM
To: amd-gfx@lists.freedesktop.org; Kuehling, Felix ;
Deucher, Alexander
Cc: Ma, Jun ; Chen, Guchun
Subject: [PATCH] drm/amdkfd: Make kfd_fill_cache_non_crat_info() as st
kfd_fill_cache_non_crat_info() is only used in kfd_topology.c,
so make it as static.
Signed-off-by: Ma Jun
Reported-by: kernel test robot
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
[AMD Official Use Only - General]
Hi @Koenig, Christian,
Can you help me review the new patch below? Thanks!
Kind regards,
Esther
-Original Message-
From: Tong Liu01
Sent: 2022年11月4日星期五 下午7:01
To: amd-gfx@lists.freedesktop.org
Cc: Andrey Grodzovsky ; Quan, Evan
; Chen, Horace ; Tuiko
On 2022/11/5 2:31, Alex Deucher wrote:
On Fri, Nov 4, 2022 at 6:05 AM Hanjun Guo wrote:
VBIOSImageOffset in struct UEFI_ACPI_VFCT is ULONG (unsigned long),
but it will be assigned to "unsigned offset", so use unsigned long
instead of unsigned for the offset, to avoid possible overflow.
ULONG
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: Song, Asher
Sent: Friday, November 4, 2022 5:30 PM
To: stalk...@gmail.com; Chen, Guchun ; Deucher, Alexander
; Quan, Evan ; ern...@gmail.com;
amd-gfx@lists.freedesktop.org
Cc: Song, Asher
Subject: [PATCH] Revert "drm/
From: Rodrigo Siqueira
[ Upstream commit ca08a1725d0d78efca8d2dbdbce5ea70355da0f2 ]
When using a device based on DCN32/321,
we have an issue where a second
4k@60Hz display does not light up,
and the system becomes unresponsive
for a few minutes. In the debug process,
it was possible to see a han
From: Rodrigo Siqueira
[ Upstream commit ca08a1725d0d78efca8d2dbdbce5ea70355da0f2 ]
When using a device based on DCN32/321,
we have an issue where a second
4k@60Hz display does not light up,
and the system becomes unresponsive
for a few minutes. In the debug process,
it was possible to see a han
From: Alvin Lee
[ Upstream commit abe4d9f03fae76c9650b0d942faf6990b35c377b ]
pipe_ctx[i] exists even if the pipe is not
in use. If the pipe is not in use it will
always have a null stream, so don't return
false in this case.
Tested-by: Daniel Wheeler
Reviewed-by: Rodrigo Siqueira
Acked-by: Qi
From: Rodrigo Siqueira
[ Upstream commit ca08a1725d0d78efca8d2dbdbce5ea70355da0f2 ]
When using a device based on DCN32/321,
we have an issue where a second
4k@60Hz display does not light up,
and the system becomes unresponsive
for a few minutes. In the debug process,
it was possible to see a han
From: Yiqing Yao
[ Upstream commit 226dcfad349f23f7744d02b24f8ec3bc4f6198ac ]
[why]
MES response time in sriov may be longer than default value
due to reset or init in other VF. A timeout value specific
to sriov is needed.
[how]
When in sriov, adjust the timeout value to calculated
worst case s
15 matches
Mail list logo
