search for: slow_down_period

Hello there, [linux-4.13/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fan.c:93]: (warning) Opposite inner 'if' condition leads to a dead code block. Source code is if (target != duty) { u16 bump_period = fan->bios.bump_period; u16 slow_down_period = fan->bios.slow_down_period; u64 delay; if (duty > target) delay = slow_down_period; else if (duty == target) delay = min(bump_period, slow_down_period) ; Last if can never be true, so call to min can never execute. Suggest code rework. Rega...

https://bugs.freedesktop.org/show_bug.cgi?id=65554 Priority: medium Bug ID: 65554 Assignee: nouveau at lists.freedesktop.org Summary: CPU lock with nouveau_fan_update QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified OS: Linux (All) Reporter: ddamienn at gmail.com

...veau/nvkm/subdev/therm/fan.c index f8fa43c8a7d2..c4aaf7473065 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fan.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fan.c @@ -90,8 +90,6 @@ nvkm_fan_update(struct nvkm_fan *fan, bool immediate, int target) if (duty > target) delay = slow_down_period; - else if (duty == target) - delay = min(bump_period, slow_down_period) ; else delay = bump_period; -- 2.39.2

From: Martin Peres <martin.peres at labri.fr> This should fix a deadlock that has been reported to us where fan_update() would hold the fan lock and try to grab the alarm_program_lock to reschedule an update. On an other CPU, the alarm_program_lock would have been taken before calling fan_update(), leading to a deadlock. We should Cc: <stable at vger.kernel.org> # 3.9+ Reported-by: