On 12/07/2026 18:39, Timur Kristóf wrote:
When DPM is turned off with the amdgpu.dpm=0 module parameter,
the thermal work queue isn't initialized so we shouldn't
schedule any work on it.
Signed-off-by: Timur Kristóf <[email protected]>
---
drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
index 832953941266..6a54566d1a68 100644
--- a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
+++ b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
@@ -7692,7 +7692,7 @@ static int si_dpm_process_interrupt(struct amdgpu_device
*adev,
break;
}
- if (queue_thermal)
+ if (queue_thermal && amdgpu_dpm)
schedule_work(&adev->pm.dpm.thermal.work);
return 0;
I don't know this code but what is suspicious to me is that there appear
to be other unguarded entry points to the un-initialized work. Like all
the flush_work() calls and one cancel_work_sync() as well.
Presumably as long as si_dpm_sw_init() is returning success when
amdgpu_dpm == 0 those two can get called?
Finding the right Fixes: target might be a good thing too.
Regards,
Tvrtko