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

Reply via email to