All of lore.kernel.org
 help / color / mirror / Atom feed
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,
					  &regval);
			...
			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

  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.