From: sashiko-bot@kernel.org
To: "Cong Nguyen" <congnt264@gmail.com>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: [PATCH v2 1/2] hwmon: (max6621) fix temperature clamp range
Date: Mon, 10 Aug 2026 05:12:58 +0000 [thread overview]
Message-ID: <20260810051259.3C53B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <9d3a4f1895a47794bb359a2a32fb1ccd6a15812c.1786334038.git.congnt264@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Reading a channel-specific alarm attribute returns the global alert status and silently clears alerts for all channels.
--
--- Patch [1]: [PATCH v2 1/2] hwmon: (max6621) fix temperature clamp range ---
commit 6a78b24a06173620d98274b9f9d004f988e65833
Author: Cong Nguyen <congnt264@gmail.com>
hwmon: (max6621) fix temperature clamp range
MAX6621_TEMP_INPUT_MIN and MAX6621_TEMP_INPUT_MAX are used to clamp the
writable offset and critical thresholds. They are defined as -127000 and
128000. Correct the limits to -128000 and 127000.
Fixes: 92b64580f14b ("hwmon: (max6621) Add support for Maxim MAX6621 temperature sensor")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4
Signed-off-by: Cong Nguyen <congnt264@gmail.com>
> diff --git a/drivers/hwmon/max6621.c b/drivers/hwmon/max6621.c
> index e86ec6d237ca6..16a3a61d25326 100644
> --- a/drivers/hwmon/max6621.c
> +++ b/drivers/hwmon/max6621.c
> @@ -17,8 +17,8 @@
>
> #define MAX6621_DRV_NAME "max6621"
> #define MAX6621_TEMP_INPUT_REG_NUM 9
> -#define MAX6621_TEMP_INPUT_MIN -127000
> -#define MAX6621_TEMP_INPUT_MAX 128000
> +#define MAX6621_TEMP_INPUT_MIN -128000
> +#define MAX6621_TEMP_INPUT_MAX 127000
[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in
max6621_read() when handling hwmon_temp_crit_alarm:
drivers/hwmon/max6621.c:max6621_read() {
...
case hwmon_temp_crit_alarm:
...
ret = regmap_read(data->regmap,
MAX6621_TEMP_ALERT_CAUSE_REG,
®val);
...
if (regval) {
ret = i2c_smbus_write_byte(data->client,
MAX6621_CLEAR_ALERT_REG);
if (ret)
return ret;
}
*val = !!regval;
...
}
Because MAX6621_TEMP_ALERT_CAUSE_REG is global, does reading a single
channel's alarm attribute incorrectly return the global alert status
regardless of the requested channel?
Furthermore, could the subsequent write to MAX6621_CLEAR_ALERT_REG silently
clear the alert state for all other channels?
Since unprivileged users can typically read these alarm attributes, would
this allow a local user to suppress system-wide thermal alarms by
continuously reading a single channel?
--
Sashiko AI review · https://sashiko.dev/#/patchset/9d3a4f1895a47794bb359a2a32fb1ccd6a15812c.1786334038.git.congnt264@gmail.com?part=1
next prev parent reply other threads:[~2026-08-10 5:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 4:27 [PATCH v2 1/2] hwmon: (max6621) fix temperature clamp range Cong Nguyen
2026-08-10 4:28 ` [PATCH v2 2/2] hwmon: (max6621) fix negative temperature offset and crit readings Cong Nguyen
2026-08-10 5:16 ` sashiko-bot
2026-08-10 6:35 ` Guenter Roeck
2026-08-10 16:26 ` Guenter Roeck
2026-08-10 5:12 ` sashiko-bot [this message]
2026-08-10 16:25 ` [PATCH v2 1/2] hwmon: (max6621) fix temperature clamp range Guenter Roeck
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=20260810051259.3C53B1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=congnt264@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.