From: sashiko-bot@kernel.org
To: "Binbin Zhou" <zhoubinbin@loongson.cn>
Cc: devicetree@vger.kernel.org, lee@kernel.org, mfd@lists.linux.dev,
conor+dt@kernel.org, robh@kernel.org
Subject: Re: [PATCH v4 5/5] thermal/drivers/loongson2: Add support for Loongson-2K0300
Date: Tue, 04 Aug 2026 12:59:26 +0000 [thread overview]
Message-ID: <20260804125926.DE9EC1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <0c2af3251d520ab04d18c14fce0a825e7b171ca5.1785829933.git.zhoubinbin@loongson.cn>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The 'old fuse' validity check uses legitimate dynamic temperature bounds, which will permanently disable sensor calibration during real thermal emergencies.
- [Medium] The return values of `regmap_read()` for chip ID registers are ignored, potentially leading to silent failures and miscalculation of temperatures.
- [Medium] Suspicious manual sign-magnitude parsing and missing sign handling for `chip_id0` calibration data.
--
--- Patch [5]: [PATCH v4 5/5] thermal/drivers/loongson2: Add support for Loongson-2K0300 ---
commit 3e3a89cf673b3132da6f690e9200a7140d2ed6ae
Author: Binbin Zhou <zhoubinbin@loongson.cn>
thermal/drivers/loongson2: Add support for Loongson-2K0300
This commit adds support for the thermal sensor on the Loongson-2K0300 SoC.
The sensor uses a 10-bit ADC and requires per-chip calibration offsets read
from syscon CHIP ID registers. A fallback formula and validity check are
included for older fuse versions.
> diff --git a/drivers/thermal/loongson2_thermal.c b/drivers/thermal/loongson2_thermal.c
> index 1a8ca2cd06f1b..51b29b60372a5 100644
> --- a/drivers/thermal/loongson2_thermal.c
> +++ b/drivers/thermal/loongson2_thermal.c
[ ... ]
> @@ -72,13 +96,54 @@ static int loongson2_thermal_set(struct loongson2_thermal_data *data,
> return 0;
> }
>
> +static int loongson2_2k0300_get_temp(struct thermal_zone_device *tz, int *temp)
> +{
> + struct loongson2_thermal_data *tdata = thermal_zone_device_priv(tz);
> + int calib_data, calib_offset, temp_mc, raw_adc;
> + u32 chip_id0 = 0, chip_id1 = 0;
> +
> + writel(0xff03, tdata->ctrl_reg + LOONGSON2_THSENS_CFG_REG);
> + raw_adc = FIELD_GET(LOONGSON2_THSENS_OUT_11B_MASK,
> + readl(tdata->ctrl_reg + LOONGSON2_THSENS_OUT_REG));
> +
> + if (tdata->flags & LS2K0300_OLD_FUSE_FLAG) {
> + *temp = raw_adc * 569 - 394700;
> + return 0;
> + }
> +
> + regmap_read(tdata->regmap_cfg, LS2K0300_CHIP_ID0, &chip_id0);
> + regmap_read(tdata->regmap_cfg, LS2K0300_CHIP_ID1, &chip_id1);
[Severity: Medium]
Is it safe to ignore the return values of these regmap_read() calls?
If regmap_read() fails due to an underlying bus or configuration error, it
will not modify chip_id0 or chip_id1, leaving them at 0. This could cause
the driver to silently compute an uncalibrated temperature without reporting
the read error.
> +
> + if (chip_id0 & LS2K0300_EXTERN_ID) {
> + calib_data = FIELD_GET(LS2K0300_ID1_VAL_MASK, chip_id1);
> + calib_offset = FIELD_GET(LS2K0300_COMP_VAL_MASK, calib_data);
> + if (calib_data & LS2K0300_COMP_SIGN_BIT)
> + calib_offset = -calib_offset;
> + } else {
> + calib_data = FIELD_GET(LS2K0300_ID0_VAL_MASK, chip_id0);
> + calib_offset = FIELD_GET(LS2K0300_COMP_VAL_MASK, calib_data);
[Severity: Medium]
Does the chip_id0 fallback path have a missing sign bit check?
The code extracts a 12-bit value into calib_data using a 12-bit mask
(LS2K0300_ID0_VAL_MASK is GENMASK(31, 20)). It then immediately applies a
15-bit mask (LS2K0300_COMP_VAL_MASK is GENMASK(14, 0)) to that 12-bit value,
which appears redundant.
Additionally, unlike the chip_id1 branch above which explicitly checks for a
sign bit and negates the offset, this branch lacks sign handling. If the
12-bit fuse data uses a sign bit, interpreting a negative value as a large
positive integer could skew the temperature calculation significantly.
> + }
> +
> + temp_mc = (raw_adc + calib_offset) * 570 - 394700;
> +
> + /* For old fuse which can not read right thermal data */
> + if (temp_mc < LS2K0300_LOWEST_VALID_TEMP || temp_mc > LS2K0300_HIGHEST_VALID_TEMP) {
[Severity: High]
Could this logic permanently disable sensor calibration during a real overheat?
If the physical CPU temperature genuinely exceeds 125 degrees Celsius during
a thermal emergency, this check will incorrectly flag the valid hardware fuse
as invalid.
It then sets the LS2K0300_OLD_FUSE_FLAG, permanently disabling calibration
for all future reads, which causes the sensor to report lower uncalibrated
temperatures exactly when accurate readings are needed to trigger a shutdown.
> + dev_warn_once(tdata->dev, "It's an old fuse, thermal %d is not right\n", temp_mc);
> + tdata->flags |= LS2K0300_OLD_FUSE_FLAG;
> + temp_mc = raw_adc * 569 - 394700;
> + }
> + *temp = temp_mc;
> +
> + return 0;
> +}
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1785829933.git.zhoubinbin@loongson.cn?part=5
next prev parent reply other threads:[~2026-08-04 12:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 12:40 [PATCH v4 0/5] thermal: loongson2: Add support for Loongson-2K0300 SoC Binbin Zhou
2026-08-04 12:42 ` [PATCH v4 1/5] thermal/drivers/loongson2: Correct thermal sensor registration loop Binbin Zhou
2026-08-04 13:01 ` sashiko-bot
2026-08-04 12:43 ` [PATCH v4 2/5] thermal/drivers/loongson2: Move thermal_ops to chip_data for SoC scalability Binbin Zhou
2026-08-04 12:55 ` sashiko-bot
2026-08-04 12:43 ` [PATCH v4 3/5] dt-bindings: mfd: syscon: Allow syscon compatible for Loongson-2K0300 chip id Binbin Zhou
2026-08-04 12:46 ` sashiko-bot
2026-08-05 6:59 ` Krzysztof Kozlowski
2026-08-12 11:25 ` (subset) " Lee Jones
2026-08-04 12:43 ` [PATCH v4 4/5] dt-bindings: thermal: loongson,ls2k-thermal: Add compatible for Loongson-2K0300 Binbin Zhou
2026-08-04 12:49 ` sashiko-bot
2026-08-04 12:43 ` [PATCH v4 5/5] thermal/drivers/loongson2: Add support " Binbin Zhou
2026-08-04 12:59 ` sashiko-bot [this message]
2026-08-05 9:43 ` [PATCH v4 0/5] thermal: loongson2: Add support for Loongson-2K0300 SoC Huacai Chen
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=20260804125926.DE9EC1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lee@kernel.org \
--cc=mfd@lists.linux.dev \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=zhoubinbin@loongson.cn \
/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.