From: sashiko-bot@kernel.org
To: "Eugene Shalygin" <eugene.shalygin@gmail.com>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: [PATCH v2 1/1] hwmon: (asus-ec-sensors) detect unconnected physical sensors
Date: Sat, 11 Jul 2026 10:18:44 +0000 [thread overview]
Message-ID: <20260711101845.1885F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260711101143.571191-2-eugene.shalygin@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Blank temperature check applies to all thermal sensors, causing false `-ENODATA` errors during extreme subzero cooling.
--
--- Patch [1]: [PATCH v2 1/1] hwmon: (asus-ec-sensors) detect unconnected physical sensors ---
commit a1732d7627cd4596df1c72251d94e446dc0be771
Author: Eugene Shalygin <eugene.shalygin@gmail.com>
hwmon: (asus-ec-sensors) detect unconnected physical sensors
This commit adds a check for specific special values (-62, -60, -40)
returned by the EC when a temperature sensor is unconnected. When these
values are detected, the driver now returns -ENODATA instead of the raw
value to the hwmon subsystem.
> diff --git a/drivers/hwmon/asus-ec-sensors.c b/drivers/hwmon/asus-ec-sensors.c
> index 29a23484cbe7b..d805de5da7b24 100644
> --- a/drivers/hwmon/asus-ec-sensors.c
> +++ b/drivers/hwmon/asus-ec-sensors.c
[ ... ]
> @@ -1310,8 +1329,12 @@ static int asus_ec_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
>
> ret = get_cached_value_or_update(dev, sidx, state, &value);
> if (!ret) {
> - *val = scale_sensor_value(value,
> - get_sensor_info(state, sidx)->type);
> + sensor_info = get_sensor_info(state, sidx);
> + if (sensor_info->type == hwmon_temp &&
> + is_blank_temperature_value(value)) {
> + return -ENODATA;
> + }
[Severity: Medium]
Could this check inadvertently cause false read errors for legitimate subzero
temperatures?
Because this filter applies broadly to all hwmon_temp sensors in
asus_ec_hwmon_read(), it appears it would intercept valid extreme negative
temperatures, such as those seen during Liquid Nitrogen cooling setups. For
fixed onboard sensors like the CPU and VRM, values like -40, -60, or -62
might represent either genuine readings or the minimum clamped value of the
sensor's thermistor table.
Does this code risk disrupting monitoring tools and fan control daemons
during extreme subzero cooling by returning -ENODATA instead of the valid
clamped temperature?
> + *val = scale_sensor_value(value, sensor_info->type);
> }
>
> return ret;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260711101143.571191-2-eugene.shalygin@gmail.com?part=1
prev parent reply other threads:[~2026-07-11 10:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-11 10:10 [PATCH v2 0/1] hwmon: (asus-ec-sensors) detect unconnected physical sensors Eugene Shalygin
2026-07-11 10:10 ` [PATCH v2 1/1] " Eugene Shalygin
2026-07-11 10:18 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260711101845.1885F1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=eugene.shalygin@gmail.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox