From: "Troy Mitchell" <troy.mitchell@linux.dev>
To: <sashiko-reviews@lists.linux.dev>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Guenter Roeck" <linux@roeck-us.net>,
"Paul Walmsley" <pjw@kernel.org>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Alexandre Ghiti" <alex@ghiti.fr>, "Yixun Lan" <dlan@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <skhan@linuxfoundation.org>,
"Randy Dunlap" <rdunlap@infradead.org>
Cc: "Troy Mitchell" <troy.mitchell@linux.dev>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-hwmon@vger.kernel.org>, <linux-riscv@lists.infradead.org>,
<spacemit@lists.linux.dev>, <linux-doc@vger.kernel.org>,
"Jean Delvare" <jdelvare@suse.de>
Subject: Re: [PATCH v4 4/6] hwmon: (lm63) Add Sensylink CTF2301 support
Date: Tue, 01 Sep 2026 14:23:42 +0800 [thread overview]
Message-ID: <DL3RJ2VF605G.2L1HBQB1CUEGA@linux.dev> (raw)
In-Reply-To: <20260831163256.784771F000E9@smtp.kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 2670 bytes --]
On Mon, Aug 31, 2026 at 04:32:56PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
> - [Medium] TEMP12_TO_REG and software caching logic fail to align with
> 12-bit hardware truncation, causing sysfs cache inconsistency.
>
> [...]
>
> @@ -121,6 +126,9 @@ static const unsigned short normal_i2c[] = { 0x18, 0x4c, 0x4e, I2C_CLIENT_END };
> 127000), 1000)
> #define TEMP8U_TO_REG(val) DIV_ROUND_CLOSEST(clamp_val((val), 0, \
> 255000), 1000)
> +#define TEMP12_FROM_REG(reg) DIV_ROUND_CLOSEST((s16)(reg) * 1000, 256)
> +#define TEMP12_TO_REG(val) DIV_ROUND_CLOSEST(clamp_val((val), -128000, \
> + 127937) * 256, 1000)
> #define TEMP11_FROM_REG(reg) ((reg) / 32 * 125)
> #define TEMP11_TO_REG(val) (DIV_ROUND_CLOSEST(clamp_val((val), -128000, \
> 127875), 125) * 32)
>
> [...]
>
> @@ -594,6 +692,21 @@ static ssize_t set_temp8(struct device *dev, struct device_attribute *devattr,
> return err;
>
> mutex_lock(&data->update_lock);
> + if (data->kind == ctf2301 && nr == 1) {
> + temp = TEMP12_TO_REG(val);
> + err = i2c_smbus_write_byte_data(client, LM63_REG_LOCAL_HIGH,
> + temp >> 8);
> + if (!err)
> + err = i2c_smbus_write_byte_data(client,
> + CTF2301_REG_LOCAL_HIGH_LSB,
> + temp & 0xf0);
> + if (!err)
> + data->temp1_max = temp;
>
> [Severity: Medium]
> Does this sequence cause the sysfs cache to become inconsistent with the
> hardware state?
>
> The TEMP12_TO_REG macro scales the value but does not align or quantize it
> to a 12-bit hardware boundary, leaving fractional bits present in the
> lowest 4 bits. Here in set_temp8, those lowest 4 bits of temp are masked
> out with 0xf0 when writing to the hardware register, but the unmasked temp
> is saved in data->temp1_max.
>
> If a user writes a temperature limit that is not a perfect multiple of
> 0.0625 degrees Celsius, will this cause the sysfs interface to return the
> un-truncated value immediately after the write, but later shift to the
> truncated value upon the next device poll?
This is a bug. TEMP12_TO_REG() currently produces an unaligned 8.8
fixed-point value. The register write discards bits 3:0, while the cache
retains them, so an immediate sysfs read can differ from the value read
back from the device after the next update.
I will fix this in the next version by quantizing the converted value to
the CTF2301's 0.0625 degree C resolution before using it for both the
register writes and the cache update.
- Troy
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2026-09-01 6:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 13:45 [PATCH v4 0/6] hwmon: (lm63) Add Sensylink CTF2301 support Troy Mitchell
2026-08-31 13:45 ` [PATCH v4 1/6] dt-bindings: vendor-prefixes: Add Sensylink Troy Mitchell
2026-08-31 13:45 ` [PATCH v4 2/6] dt-bindings: hwmon: Move LM63 family to a dedicated binding Troy Mitchell
2026-08-31 13:45 ` [PATCH v4 3/6] dt-bindings: hwmon: Add Sensylink CTF2301 Troy Mitchell
2026-08-31 13:45 ` [PATCH v4 4/6] hwmon: (lm63) Add Sensylink CTF2301 support Troy Mitchell
[not found] ` <20260831163256.784771F000E9@smtp.kernel.org>
2026-09-01 6:23 ` Troy Mitchell [this message]
2026-08-31 13:45 ` [PATCH v4 5/6] riscv: dts: spacemit: Add K3 I2C6 pinctrl state Troy Mitchell
2026-08-31 13:45 ` [PATCH v4 6/6] riscv: dts: spacemit: Add CTF2301 on K3 CoM260 Troy Mitchell
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=DL3RJ2VF605G.2L1HBQB1CUEGA@linux.dev \
--to=troy.mitchell@linux.dev \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=dlan@kernel.org \
--cc=jdelvare@suse.de \
--cc=krzk+dt@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux@roeck-us.net \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=rdunlap@infradead.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=skhan@linuxfoundation.org \
--cc=spacemit@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