similar to: [PATCH] drm/nouveau/hwmon: fix use of integer as a pointer

Replace the use of 0 in the pointer assignment with NULL to address the following sparse warning: drivers/gpu/drm/nouveau/nouveau_hwmon.c:744:29: warning: Using plain integer as NULL pointer Signed-off-by: Wambui Karuga <wambui.karugax at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_hwmon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

On Tue, Dec 31, 2019 at 11:57:34PM +0300, Wambui Karuga wrote: > Replace the use of 0 in the pointer assignment with NULL to address the > following sparse warning: > drivers/gpu/drm/nouveau/nouveau_hwmon.c:744:29: warning: Using plain integer as NULL pointer > > Signed-off-by: Wambui Karuga <wambui.karugax at gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter at

This patch creates a special group attributes for attrs like "*auto_point*". We check if we have support for them, and if we do, we gather them all in an attribute_group's structure which is the parameter regarding special groups of hwmon_device_register_with_info. --- drivers/gpu/drm/nouveau/nouveau_hwmon.c | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1

This patch creates a special group attributes for attrs like "*auto_point*". We check if we have support for them, and if we do, we gather them all in an attribute_group's structure which is the parameter regarding special groups of hwmon_device_register_with_info. Signed-off-by: Oscar Salvador <osalvador.vilardaga at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_hwmon.c |

This patch creates a special group attributes for attrs like "*auto_point*". We check if we have support for them, and if we do, we gather them all in an attribute_group's structure which is the parameter regarding special groups of hwmon_device_register_with_info. Signed-off-by: Oscar Salvador <osalvador.vilardaga at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_hwmon.c |

This patch creates special group attributes for special attrs like "*auto_point*". We check if we need them, and if we do, we set them up in special_groups structure, that then we pass to hwmon_device_register_with_info. --- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig 2017-04-13 10:13:26.331391326 +0200 +++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c 2017-04-13

A NV34 GPU was seeing temp and pwm entries in hwmon, which would error out when read. These should not have been visible, but also the whole hwmon object should just not have been registered in the first place. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/nouveau_hwmon.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git

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

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

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

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

Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/include/nvif/device.h | 1 + drm/nouveau/nouveau_hwmon.c | 39 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 40 insertions(+) diff --git a/drm/nouveau/include/nvif/device.h b/drm/nouveau/include/nvif/device.h index e0ed2f4..bcb9817 100644 --- a/drm/nouveau/include/nvif/device.h +++

Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/nouveau_hwmon.c | 39 +++++++++++++++++++-------------------- 1 file changed, 19 insertions(+), 20 deletions(-) diff --git a/drm/nouveau/nouveau_hwmon.c b/drm/nouveau/nouveau_hwmon.c index c4f77f5..a630192 100644 --- a/drm/nouveau/nouveau_hwmon.c +++ b/drm/nouveau/nouveau_hwmon.c @@ -643,9 +643,6 @@

Sorry for that. I'll split the patch and I'll come again ;) El dia 11/04/2017 22:12, "Karol Herbst" <karolherbst at gmail.com> va escriure: thanks for the work, but could you please split that patch? It looks like you are doing several things at once and it isn't really easy to review like this. And it isn't bisectable. If there are clean ups here, please do it

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

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,

Registration of the hwmon device will fail on non-PCI systems since dev->pdev is NULL in that case. Use the more generic drm_device::dev member that points to the same and is always set no matter the platform. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nouveau_hwmon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- drm/nouveau/nouveau_hwmon.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/drm/nouveau/nouveau_hwmon.c b/drm/nouveau/nouveau_hwmon.c index 71f764b..3d4672a 100644 --- a/drm/nouveau/nouveau_hwmon.c +++ b/drm/nouveau/nouveau_hwmon.c @@ -596,6 +596,32 @@

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