similar to: drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c: broken emergency poweroff handling

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c index b9703c0..adb1deb 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c @@ -120,6 +120,11 @@ nvkm_therm_sensor_event(struct nvkm_therm *therm, enum nvkm_therm_thrs thrs, struct work_struct *work; work =

Thanks for the pointer. But I don't like this patch. If you find a bug, make a bug report or just fix it if you know the fix already. Or write something in IRC. Or write on the Mailing list as a general question or something else But I really don't agree on doing it this way. You would have needed like the same amount of time to actual fix the problem. Anyway, for adding a printk:

From: Colin Ian King <colin.king at canonical.com> Array thresolds should be named thresholds, rename it. Also make it static static const char * const Signed-off-by: Colin Ian King <colin.king at canonical.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

The current hwmon code doesn't check if the returned value was actually an error. Since Kepler temperature sensors are able to report negative values. Since Pascal (and maybe earlier) we have sensors with improved precision. Adjust the nvkm_get_temp method to be able to deal with those changes and let hwmon return an error properly. Signed-off-by: Karol Herbst <karolherbst at

The current hwmon code doesn't check if the returned value was actually an error. Since Kepler temperature sensors are able to report negative values. Those negative values are not for error reporting, but rather when you buried your GPU in snow somewhere in Antarctica and still want a valid temperature to be reported (unverified). Since Pascal (and maybe earlier) we have sensors with

On Wed, Nov 22, 2017 at 1:32 AM, Martin Peres <martin.peres at free.fr> wrote: > On 17/11/17 02:04, Karol Herbst wrote: >> The current hwmon code doesn't check if the returned value was actually an >> error. >> >> Since Kepler temperature sensors are able to report negative values. Those >> negative values are not for error reporting, but rather when you

+ the same for shutdown threshold - seems impossible, but shutdown can fail. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/core/subdev/therm/temp.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/therm/temp.c b/drivers/gpu/drm/nouveau/core/subdev/therm/temp.c index bf9b3ce..8f27b44

As you changed the return value of `temp_get()` to solely be the error code, or absence of an error, I would change all those tests that checked whether the returned value was strictly less, or greater than, 0 to now only compare against 0 (no error). For example, if (therm && therm->attr_get && nvkm_therm_temp_get(therm, &val) < 0) if

On 22/11/17 03:42, Karol Herbst wrote: > On Wed, Nov 22, 2017 at 1:32 AM, Martin Peres <martin.peres at free.fr> wrote: >> On 17/11/17 02:04, Karol Herbst wrote: >>> The current hwmon code doesn't check if the returned value was actually an >>> error. >>> >>> Since Kepler temperature sensors are able to report negative values. Those

On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline <jcline at redhat.com> wrote: > > The temp_get() function currently returns negative error numbers or a > temperature. However, the thermal sensors can (in theory) measure > negative temperatures. Some implementations of temp_get() correctly > clamp negative temperature readings to 0 so that users do not mistake > them for

On 17/11/17 02:04, Karol Herbst wrote: > The current hwmon code doesn't check if the returned value was actually an > error. > > Since Kepler temperature sensors are able to report negative values. Those > negative values are not for error reporting, but rather when you buried > your GPU in snow somewhere in Antarctica and still want a valid > temperature to be reported

On Wed, Sep 16, 2020 at 10:03:22PM +0200, Karol Herbst wrote: > On Wed, Sep 16, 2020 at 10:01 PM Karol Herbst <kherbst at redhat.com> wrote: > > > > On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline <jcline at redhat.com> wrote: > > > > > > The temp_get() function currently returns negative error numbers or a > > > temperature. However, the thermal

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;

> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15: NV5 in another PC (secondary card in x86-64) made the systrem crash on boot, in nvkm_therm_clkgate_fini. -- Meelis Roos (mroos at linux.ee)

On Wed, Feb 14, 2018 at 9:35 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos <mroos at linux.ee> wrote: >>> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15: >> >> NV5 in another PC (secondary card in x86-64) made the systrem crash on >> boot, in nvkm_therm_clkgate_fini. > > Mind

Actually this was brought up to me already, there's a fix on the mailing list for this I reviewed a little while ago from nvidia that we should pull in: https://patchwork.freedesktop.org/patch/203205/ Would you guys mind confirming that this patch fixes your issues? On Wed, 2018-02-14 at 18:41 +0100, Pierre Moreau wrote: > On 2018-02-14 — 09:36, Ilia Mirkin wrote: > > On Wed, Feb

On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos <mroos at linux.ee> wrote: >> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15: > > NV5 in another PC (secondary card in x86-64) made the systrem crash on > boot, in nvkm_therm_clkgate_fini. Mind booting with nouveau.debug=trace? That should hopefully tell us more exactly which thing is dying. If you have a

On 2018-02-14 — 09:36, Ilia Mirkin wrote: > On Wed, Feb 14, 2018 at 9:35 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > > On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos <mroos at linux.ee> wrote: > >>> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15: > >> > >> NV5 in another PC (secondary card in x86-64) made the systrem

This is 4.16-rc1+todays git ona lowly P4 with NV5, worked fine in 4.15: [ 7.361155] nouveau 0000:01:00.0: NVIDIA NV05 (20154000) [ 7.386601] nouveau 0000:01:00.0: bios: version 02.05.19.03.00 [ 7.386715] nouveau 0000:01:00.0: bios: DCB table not found [ 7.386983] nouveau 0000:01:00.0: bios: DCB table not found [ 7.387166] nouveau 0000:01:00.0: bios: DCB table not found [

The temp_get() function currently returns negative error numbers or a temperature. However, the thermal sensors can (in theory) measure negative temperatures. Some implementations of temp_get() correctly clamp negative temperature readings to 0 so that users do not mistake them for errors, but some, like gp100_temp_get(), do not. Rather than relying on implementations remembering to clamp values,