combinations, and sent as an RFC to encourage discussion.
Signed-off-by: Zhang Yuhao
Signed-off-by: Mingcong Bai
Tested-by: Mingcong Bai
---
drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig
b/drivers/gp
From: Mingcong Bai
As this component hooks into userspace API, it should be assumed that it
will play well with non-4KiB/64KiB pages.
Use `PAGE_SIZE' as the final reference for page alignment instead.
Cc: sta...@vger.kernel.org
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver
From: Mingcong Bai
Similar to the preceding patch for GuC (and with the same references),
Intel GPUs expects command buffers to align to 4KiB boundaries.
Current code uses `PAGE_SIZE' as an assumed alignment reference but 4KiB
kernel page sizes is by no means a guarantee. On 16KiB-paged ke
From: Mingcong Bai
The bo/ttm interfaces with kernel memory mapping from dedicated GPU
memory. It is not correct to assume that SZ_4K would suffice for page
alignment as there are a few hardware platforms that commonly uses non-
4KiB pages - for instance, 16KiB is the most commonly used kernel
hat's strange... I have just resent the series.
Best Regards,
Mingcong Bai
From: Mingcong Bai
Per the "Firmware" chapter in "drm/xe Intel GFX Driver", as well as
"Volume 8: Command Stream Programming" in "Intel® Arc™ A-Series Graphics
and Intel Data Center GPU Flex Series Open-Source Programmer's Reference
Manual For the discrete
Shang Yatsen <429839...@qq.com>
Signed-off-by: Shang Yatsen <429839...@qq.com>
Signed-off-by: Mingcong Bai
---
Mingcong Bai (5):
drm/xe/bo: fix alignment with non-4KiB kernel page sizes
drm/xe/guc: use GUC_SIZE (SZ_4K) for alignment
drm/xe/regs: fix RING_CTL_SIZE(size)
From: Mingcong Bai
It appears that the xe_res_cursor also assumes 4KiB alignment.
Current implementation uses `PAGE_SIZE' as an assumed alignment reference,
but 4KiB kernel page sizes is by no means a guarantee. On 16KiB-paged
kernels, this causes driver failures during boot up:
[ 23.2
Shang Yatsen <429839...@qq.com>
Signed-off-by: Shang Yatsen <429839...@qq.com>
Signed-off-by: Mingcong Bai
---
Mingcong Bai (5):
drm/xe/bo: fix alignment with non-4KiB kernel page sizes
drm/xe/guc: use GUC_SIZE (SZ_4K) for alignment
drm/xe/regs: fix RING_CTL_SIZE(size)
From: Mingcong Bai
Per the "Firmware" chapter in "drm/xe Intel GFX Driver", as well as
"Volume 8: Command Stream Programming" in "Intel® Arc™ A-Series Graphics
and Intel Data Center GPU Flex Series Open-Source Programmer's Reference
Manual For the discrete
From: Mingcong Bai
It appears that the xe_res_cursor also assumes 4KiB alignment.
Current implementation uses `PAGE_SIZE' as an assumed alignment reference,
but 4KiB kernel page sizes is by no means a guarantee. On 16KiB-paged
kernels, this causes driver failures during boot up:
[ 23.2
From: Mingcong Bai
Similar to the preceding patch for GuC (and with the same references),
Intel GPUs expects command buffers to align to 4KiB boundaries.
Current code uses `PAGE_SIZE' as an assumed alignment reference but 4KiB
kernel page sizes is by no means a guarantee. On 16KiB-paged ke
From: Mingcong Bai
As this component hooks into userspace API, it should be assumed that it
will play well with non-4KiB/64KiB pages.
Use `PAGE_SIZE' as the final reference for page alignment instead.
Cc: sta...@vger.kernel.org
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver
From: Mingcong Bai
The bo/ttm interfaces with kernel memory mapping from dedicated GPU
memory. It is not correct to assume that SZ_4K would suffice for page
alignment as there are a few hardware platforms that commonly uses non-
4KiB pages - for instance, 16KiB is the most commonly used kernel
Hi Matt,
在 2025/2/26 12:43, Matthew Brost 写道:
On Wed, Feb 26, 2025 at 10:00:22AM +0800, Mingcong Bai via B4 Relay wrote:
From: Mingcong Bai
As this component hooks into userspace API, it should be assumed that it
will play well with non-4K/64K pages.
Use `PAGE_SIZE' as the final refe
Bai via B4 Relay wrote:
From: Mingcong Bai
The bo/ttm interfaces with kernel memory mapping from dedicated GPU
memory. It is not correct to assume that SZ_4K would suffice for page
alignment as there are a few hardware platforms that commonly uses non-4K
pages - for instance, currently, Loongson
在 2025/2/26 12:43, Matthew Brost 写道:
On Wed, Feb 26, 2025 at 10:00:22AM +0800, Mingcong Bai via B4 Relay wrote:
From: Mingcong Bai
As this component hooks into userspace API, it should be assumed that it
will play well with non-4K/64K pages.
Use `PAGE_SIZE' as the final reference for
Hi Matt,
在 2025/2/26 12:18, Matthew Brost 写道:
On Tue, Feb 25, 2025 at 09:13:09PM -0600, Lucas De Marchi wrote:
On Wed, Feb 26, 2025 at 10:00:18AM +0800, Mingcong Bai via B4 Relay wrote:
From: Mingcong Bai
The bo/ttm interfaces with kernel memory mapping from dedicated GPU
memory. It is not
From: Mingcong Bai
It appears that the xe_res_cursor also assumes 4K alignment.
Current code uses `PAGE_SIZE' as an assumed alignment reference but 4K
kernel page sizes is by no means a guarantee. On 16K-paged kernels, this
causes driver failures during boot up:
[ 23.2
From: Mingcong Bai
Similar to the preceding patch for GuC (and with the same references),
Intel DG1 and DG2 GPUs expects command buffers to align to 4K boundaries.
Current code uses `PAGE_SIZE' as an assumed alignment reference but 4K
kernel page sizes is by no means a guarantee. On 16K-
From: Mingcong Bai
Per the "Firmware" chapter in "drm/xe Intel GFX Driver", as well as
"Volume 8: Command Stream Programming" in "Intel® Arc™ A-Series Graphics
and Intel Data Center GPU Flex Series Open-Source Programmer's Reference
Manual For the discrete
From: Mingcong Bai
As this component hooks into userspace API, it should be assumed that it
will play well with non-4K/64K pages.
Use `PAGE_SIZE' as the final reference for page alignment instead.
Cc: sta...@vger.kernel.org
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver
From: Mingcong Bai
The bo/ttm interfaces with kernel memory mapping from dedicated GPU
memory. It is not correct to assume that SZ_4K would suffice for page
alignment as there are a few hardware platforms that commonly uses non-4K
pages - for instance, currently, Loongson 3A5000/6000 devices (of
ream,
https://github.com/AOSC-Tracking/linux/tree/aosc/v6.13.3
[^3]: Delicious hot pot!
https://repo.aosc.io/ahvl/sample-videos-20250223.tar.zst
Suggested-by: Kexy Biscuit
Co-developed-by: Shang Yatsen <429839...@qq.com>
Signed-off-by: Shang Yatsen <429839...@qq.com>
S
ream,
https://github.com/AOSC-Tracking/linux/tree/aosc/v6.13.3
[^3]: Delicious hot pot!
https://repo.aosc.io/ahvl/sample-videos-20250223.tar.zst
Suggested-by: Kexy Biscuit
Co-developed-by: Shang Yatsen <429839...@qq.com>
Signed-off-by: Shang Yatsen <429839...@qq.com>
S
6.8-rc1.
While this is harmless as the definitions did not change, so no compiler
warning was observed.
Drop this line anyway for the sake of correctness.
Cc: # v6.8-rc1+
Fixes: b79e8fd954c4 ("drm/xe: Remove dependency on intel_engine_regs.h")
Signed-off-by: Mingcong Bai
---
drivers/gp
Hi all,
在 2025/2/25 15:18, Mingcong Bai 写道:
Commit b79e8fd954c4 ("drm/xe: Remove dependency on intel_engine_regs.h")
introduced an internal set of engine registers, however, as part of this
change, it has also introduced two duplicate `define' lines for
`RING_CTL_SIZE(size)&#x
6.8-rc1.
While this is harmless as the definitions did not change, so no compiler
warning was observed.
Drop this line anyway for the sake of correctness.
Cc: # v6.8-rc1+
Fixes: b79e8fd954c4 ("drm/xe: Remove dependency on intel_engine_regs.h")
Signed-off-by: Mingcong Bai
---
drivers/gp
intainers may have a better idea on this).
Reported-By: Yang Wu
Tested-by: Yang Wu
Suggested-by: Mingcong Bai
looking at (and as distro maintainers, what we should be looking out
for).
Alex, would you care to elaborate?
Best Regards,
Mingcong Bai
Regards,
Dave.
drm-fixes-2024-11-17:
drm/amdgpu regression fix for 6.12-rc8
amdgpu:
- revert patch to fix swsmu regression
The following changes si
&bo->tbo.base);
+ ttm_bo_get(&bo->tbo);
return bo;
}
void radeon_bo_unref(struct radeon_bo **bo)
{
+ struct ttm_buffer_object *tbo;
+
if ((*bo) == NULL)
return;
- drm_gem_object_put(&(*bo)->tbo.base);
+ tbo = &((*bo)->tbo);
+ ttm_bo_put(tbo);
*bo = NULL;
}
Best Regards,
Mingcong Bai
The ctx->hw is dereferencing before null checking, so move
it after checking.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
b/drivers/gpu/drm/msm/disp/d
The fan->base is dereferencing before null checking, so move
it after checking.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c
b/drivers/
The phys_enc->wb_idx is dereferencing before null checking, so move
it after checking.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
Return boolean values ("true" or "false") instead of 1 or 0 from bool
functions.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c
b/driver
Fixes coccicheck warning:
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:1476:2-3: Unneeded semicolon
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b
Return boolean values ("true" or "false") instead of 1 or 0 from bool
functions.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/amdkfd/kfd_int_process_v11.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_int_proc
The function check_pixel_format has an unsigned return type, but returns a
negative constant to indicate an error condition. So we change unsigned
to int.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/kmb/kmb_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
After alloc fail, we do not need to kfree.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index ec709997c9c7..5fb3e69c04c4 100644
--- a
aux_rep only memset but no use at all, so we drop it.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
index 8e814000db62
Since mdp5_state is initialized twice at the same time, so
we make code simple and easy to understand by delete one.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
b
The pointer dc is dereferencing pointer plane_state before plane_state
is being null checked. Fix this by assigning plane_state->ctx->dc to
dc only if plane_state is not NULL, otherwise just NULL.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2
Smatch reports the following:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:2174
dcn10_enable_vblanks_synchronization() warn: if statement not indented
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 14 +++---
1 file
but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Device initialisation
drivers/video/fbdev/pm2fb.c:1714: warning: This comment starts with '/**',
but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Device removal.
report by coccicheck:
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:1951:2-3: Unneeded semicolon
Fixes: c543dcbe4237 ("drm/amdgpu/vcn: Add VCN ras error query support")
Signed-off-by: Haowen Bai
---
V1->V2: change title; change Fixed info;
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 2 +-
1
bios could be null without checking null and return in this function,
but still dereference bios[0xf5].
Signed-off-by: Haowen Bai
---
drivers/video/fbdev/sis/sis_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/sis/sis_main.c
b/drivers/video/fbdev
report by coccicheck:
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:1951:2-3: Unneeded semicolon
fixed c543dcb ("drm/amdgpu/vcn: Add VCN ras error query support")
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
WARNING: Statements should start on a tabstop
WARNING: Missing a blank line after declarations
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/gma500/mid_bios.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mid_bios.c
b/drivers/gpu/drm/gma500
The pointer edid_buf is dereferencing pointer edid before edid is being
null checked. Fix this by assigning edid->raw_edid to edid_buf only if
edid is not NULL, otherwise just NULL.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
1 file chan
The value actual_pix_clk_100Hz is dereferencing pointer pix_clk_params
before pix_clk_params is being null checked. Fix this by assigning
pix_clk_params->requested_pix_clk_100hz to actual_pix_clk_100Hz only if
pix_clk_params is not NULL, otherwise just NULL.
Signed-off-by: Haowen
This fixes the following sparse warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:865:16:
warning: Using
plain integer as NULL pointer
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 2 +-
1 file changed, 1 insertion(+), 1
Clean up the following includecheck warning:
drivers/gpu/drm/drm_gem_shmem_helper.c: linux/module.h is
included more than once.
No functional change.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm
This fixes the following sparse warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/rc_calc_fpu.c:71:40: warning:
Using
plain integer as NULL pointer
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
This fixes the following sparse warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1910:16: warning:
Using
plain integer as NULL pointer
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
r_ovl is NULL but dereferenced
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/omapdrm/omap_overlay.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_overlay.c
b/drivers/gpu/drm/omapdrm/omap_overlay.c
index 10730c9..d09aaf6 100644
--- a/drivers/gpu/drm/omapdrm
Fix the following coccicheck warning:
drivers/video/fbdev/offb.c:415:13-14: WARNING comparing pointer to 0
Signed-off-by: Haowen Bai
---
drivers/video/fbdev/offb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index
ode properly.
But that happens so rarely and the driver is not developed further
that we decided to not address this any more.
Ah, okay.
Regards,
Christian.
Am 01.02.22 um 08:40 schrieb Jia-Ju Bai:
Hello,
My static analysis tool reports a possible deadlock in the radeon
driver in Linux
I think this timeout can cause
inefficient execution.
I am not quite sure whether these possible problems are real and how to
fix them if they are real.
Any feedback would be appreciated, thanks :)
Best wishes,
Jia-Ju Bai
Hello,
Could you please provide the feedback to my previous report?
Thanks a lot :)
Best wishes,
Jia-Ju Bai
On 2021/9/15 17:39, Jia-Ju Bai wrote:
Hello,
My static analysis tool reports a possible ABBA deadlock in the amdgpu
driver in Linux 5.10:
amdgpu_debugfs_process_reg_op
andle_to_fd() are
concurrently executed, the deadlock can occur.
I am not quite sure whether this possible deadlock is real and how to
fix it if it is real.
Any feedback would be appreciated, thanks :)
Reported-by: TOTE Robot
Best wishes,
Jia-Ju Bai
idx_mutex); --> Line 3697 (Lock A)
When amdgpu_debugfs_process_reg_op() and
amdgpu_set_power_dpm_force_performance_level() are concurrently
executed, the deadlock can occur.
I am not quite sure whether this possible deadlock is real and how to
fix it if it is real.
Any feedback would be appreciated, thanks :)
Reported-by: TOTE Robot
Best wishes,
Jia-Ju Bai
On 2021/3/8 17:18, Chris Wilson wrote:
Quoting Jia-Ju Bai (2021-03-08 08:59:52)
When i915_random_order() returns NULL to order, no error return code of
igt_buddy_alloc_smoke() is assigned.
To fix this bug, err is assigned with -EINVAL in this case.
It would not be EINVAL since that is used
When kcalloc() returns NULL to tsk or thread, no error code of
igt_threaded_blt() is returned.
To fix this bug, -ENOMEM is returned as error code.
Fixes: 0e99f939f08f ("drm/i915/selftests/blt: add some kthreads into the mix")
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
d
When i915_random_order() returns NULL to order, no error return code of
igt_buddy_alloc_smoke() is assigned.
To fix this bug, err is assigned with -EINVAL in this case.
Fixes: 1fe3818d17c9 ("drm/i915/selftests: try to rein in alloc_smoke")
Reported-by: TOTE Robot
Signed-off-by:
Add error return code in error hanlding code of amdgpu_acpi_init().
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu
When bitmap_empty() or feature->feature_num triggers an error,
no error return code of smu_v11_0_set_allowed_mask() is assigned.
To fix this bug, ret is assigned with -EINVAL as error return code.
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/amd/pm/swsmu/sm
may occur.
To fix this bug, connector->encoder is checked before being used.
This bug is found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/radeon/radeon_connectors.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driv
tatic analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/qxl/qxl_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 8b319ebbb0fb..fae18ef1ba59 100644
--- a/driver
:
amdgpu_mm_wreg in dce_v6_0_audio_endpt_rreg
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c, 125:
_raw_spin_lock_irqsave in dce_v6_0_audio_endpt_rreg
Note that [FUNC_PTR] means a function pointer call is used.
These bugs are found by my static analysis tool DSAC.
Best wishes,
Jia-Ju Bai
igure that out.
Okay, thanks for your explanation :)
Besides, I find that amdgpu_virt_kiq_rreg() calls msleep(), so mdelay()
should be used instead.
Best wishes,
Jia-Ju Bai
Am 15.09.2018 11:18 schrieb Jia-Ju Bai :
Sorry, I am still not clear why the call chain I proposed is incorrect...
I f
amdgpu_ring_alloc() never calls amdgpu_uvd_ring_begin_use()?
Thanks in advance.
Best wishes,
Jia-Ju Bai
Regards,
Christian.
Am 15.09.2018 10:59 schrieb Jia-Ju Bai :
The driver may sleep with holding a spinlock.
The function call paths (from bottom to top) in Linux-4.17 are:
[FUNC
from WREG32() or RREG32()?
Best wishes,
Jia-Ju Bai
On 2018/9/15 17:10, Koenig, Christian wrote:
amdgpu_ring_alloc() does call amdgpu_uvd_begin_use(), but never in the
call chain you proposed.
Thinking about it I actually don't see a way a statically analysis
could ever figure that out.
with GFP_ATOMIC.
This bug is found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/drm_mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 3166026a1874..2486121a78d4 100644
--- a/drivers
radeon_test_ring_sync() and radeon_test_ring_sync2() are never
called in atomic context.
They call mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
nv40_sensor_setup() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm
nv50_sensor_setup() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm
si_pcie_gen3_enable() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/radeon/si.c | 2 +-
1
myself.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/radeon/r600.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index e06e2d8feab3..de5f6d9f251e 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b
cik_pcie_gen3_enable() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/radeon/cik.c | 2 +-
1
r100_asic_reset() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep() and usleep_range().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/radeon
r300_asic_reset() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep() and usleep_range().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/radeon
rs600_asic_reset() is never called in atomic context.
They call mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep() and usleep_range().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/radeon
broadsheetfb is a platform driver and it should not be used on x86.
It should be used only by single ARM PXA board, so adding the
dependency in Kconfig.
Signed-off-by: Jia-Ju Bai
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video
On 2018/7/26 22:34, Bartlomiej Zolnierkiewicz wrote:
On Thursday, July 26, 2018 10:17:44 PM bai wrote:
In Linux-4.16, drivers/video/fbdev/broadsheetfb.c,
158. static void broadsheet_mmio_send_cmdargs(...) {
..
163. par->board->mmio_write(...);
ssignment of the
function pointer ".mmio_write" in the kernel code.
So calling the function pointer in lines 163 and 166 may cause a null
pointer dereference.
In this file, there are many calls to this function pointer...
Best wishes,
Jia-Ju Bai
___
.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/amd/amdgpu/cik.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c b/drivers/gpu/drm/amd/amdgpu/cik.c
index 0df22030e713..5b7fab2c2008 100644
--- a/drivers/gpu/drm/amd/amdgpu/cik.c
+++ b/drivers/gpu/drm
g.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/ast/ast_post.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
00()
calls mdelay() to busily wait.
This is not necessary and can be replaced with msleep() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/ast/ast_post.c | 2 +-
1 file c
sy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000
SAC) and checked by my code
review.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/drm_mm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 61a1c8e..5b9965d 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/
Oh, sorry, I will send the patches for each driver.
Thanks,
Jia-Ju Bai
On 2017/10/9 16:17, Greg KH wrote:
On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote:
The drivers vt6655 and gma500 call pci_set_power_state under a spinlock, which
may sleep.
The function call paths are
m, the spinlock is released before gma_resume_pci, and it is acquired
again after gma_resume_pci.
This bug is found by my static analysis tool and my code review.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/gma500/power.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/
bugs are found by my static analysis tool and my code review.
Signed-off-by: Jia-Ju Bai
---
drivers/pci/pci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 6078dfc..7b763a3 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
rs/pci/pci.c.
These bugs are found by my static analysis tool and my code review.
Thanks,
Jia-Ju Bai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
The driver may sleep under a spin lock, and the function call path is:
psbfb_2d_submit (acquire the lock by spin_lock_irqsave)
psb_2d_wait_available
psb_spank
msleep --> may sleep
To fix it, the "msleep" is replaced with "mdelay" in psb_spank.
Signed-off-by: J
96 matches
Mail list logo
