Re: [PATCH] thermal: qcom-spmi-adc-tm5: fix all temperature reads failing with -EINVAL

[Mark Esler <mark@markesler.com>]

On Fri, Aug 07, 2026 at 07:39:37PM -0800, Paul Hollinsky wrote:
> adc_tm5_get_temp() rejects any iio_read_channel_processed() return value
> that is not IIO_VAL_INT. Since commit bb21ee31f575 ("iio: Fix
> iio_multiply_value use in iio_read_channel_processed_scale"),
> iio_read_channel_processed() returns 0 on success, per its documented
> contract, instead of passing through the value type from the underlying
> read.
> 
> Since IIO_VAL_INT is 1, every successful read now takes the error path,
> so get_temp() returns -EINVAL unconditionally and every ADC-TM5 thermal
> zone is dead: with no valid temperature readings the core cannot
> evaluate trip points. Observed on a SC7180 Trogdor Chromebook (Lenovo
> IdeaPad Duet 3 / wormdingler), where the charger and skin-temp zones
> report an error on every read.
> 
> The check no longer serves its original defensive purpose either: since
> commit 05f958d003c9 ("iio: Improve iio_read_channel_processed_scale()
> precision"), fractional value types are folded into the integer result
> by iio_multiply_value() inside the IIO core, so the return value carries
> no information beyond success or failure. Just drop the check and rely
> on the ret < 0 test above it.
> 
> qcom-spmi-adc-tm5 is the only iio_read_channel_processed() consumer in
> tree still testing the return value this way.
> 
> Fixes: bb21ee31f575 ("iio: Fix iio_multiply_value use in iio_read_channel_processed_scale")
> Cc: stable@vger.kernel.org # 6.18+
> Signed-off-by: Paul Hollinsky <phollinsky@holtechnik.com>
> ---
>  drivers/thermal/qcom/qcom-spmi-adc-tm5.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/thermal/qcom/qcom-spmi-adc-tm5.c b/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
> index bb6222c8cc5f..af72db6299cd 100644
> --- a/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
> +++ b/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
> @@ -369,9 +369,6 @@ static int adc_tm5_get_temp(struct thermal_zone_device *tz, int *temp)
>  	if (ret < 0)
>  		return ret;
>  
> -	if (ret != IIO_VAL_INT)
> -		return -EINVAL;
> -
>  	return 0;
>  }
>  
> -- 
> 2.55.0
> 

This looks like the right fix. Bumping it since it's been a few weeks
with no reply.

Rakesh Kota already fixed this same regression in linux-next
(0c569e22020f, "thermal/drivers/qcom-spmi-adc-tm5: Drop IIO_VAL_INT check
in adc_tm5_get_temp", applied 2026-07-27), but it went in without Cc:
stable, so it never reached a stable branch. Paul's patch has the tag
this needs.

It also hits sc8280xp laptops (ThinkPad X13s, Huawei Gaokun 3, Microsoft
Arcata) through the same qcom,spmi-adc-tm5 compatible string. On the X13s
it's the only software throttling path on a fanless chassis: no
cooling-device entries anywhere in sc8280xp.dtsi's CPU thermal zones,
just the board-level skin zone. The zone stays enabled, since it's
threshold-interrupt rather than polled, but get_temp() always returns
-EINVAL, so no trip ever evaluates. During an 8-core kernel build the
skin thermistor hit 73.7°C, past its own 73°C critical trip, with zero
throttling applied.

We've had 0c569e22020f backported onto our own 7.1.10- and 7.2-based
kernels for a ~week now, confirmed clean: the zone comes back enabled
with correct trip points, no disable message. Neither linux-7.1.y
(7.1.10) nor linux-7.2.y (7.2) has picked it up upstream yet.

Mark