linux-kernel - Re: [PATCH v3 2/2] thermal: thermal-generic-adc: add temperature sensor channel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f56596fe-92e8-481b-b15b-29b531eaec32@arm.com>
Date: Wed, 5 Mar 2025 14:37:23 +0000
From: Lukasz Luba <lukasz.luba@....com>
To: Svyatoslav Ryhel <clamor95@...il.com>
Cc: linux-pm@...r.kernel.org, devicetree@...r.kernel.org,
 Jonathan Cameron <jic23@...nel.org>, Laxman Dewangan <ldewangan@...dia.com>,
 Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Rob Herring <robh@...nel.org>,
 Daniel Lezcano <daniel.lezcano@...aro.org>, Zhang Rui <rui.zhang@...el.com>,
 linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH v3 2/2] thermal: thermal-generic-adc: add temperature
 sensor channel

On 3/5/25 10:06, Svyatoslav Ryhel wrote:
> ср, 5 бер. 2025 р. о 11:52 Lukasz Luba <lukasz.luba@....com> пише:
>>
>>
>>
>> On 3/3/25 12:21, Svyatoslav Ryhel wrote:
>>> To avoid duplicating sensor functionality and conversion tables, this design
>>> allows converting an ADC IIO channel's output directly into a temperature IIO
>>> channel. This is particularly useful for devices where hwmon isn't suitable
>>> or where temperature data must be accessible through IIO.
>>>
>>> One such device is, for example, the MAX17040 fuel gauge.
>>>
>>> Signed-off-by: Svyatoslav Ryhel <clamor95@...il.com>
>>> ---
>>>    drivers/thermal/thermal-generic-adc.c | 54 ++++++++++++++++++++++++++-
>>>    1 file changed, 53 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/thermal/thermal-generic-adc.c b/drivers/thermal/thermal-generic-adc.c
> ...
>>>
>>> +static const struct iio_chan_spec gadc_thermal_iio_channel[] = {
>>> +     {
>>> +             .type = IIO_TEMP,
>>> +             .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
>>
>> I would add the IIO_CHAN_INFO_SCALE and say it's in milli-degrees.
>>
> 
> I have hit this issue already with als sensor. This should definitely
> be a IIO_CHAN_INFO_PROCESSED since there is no raw temp data we have,
> it gets processed into temp data via conversion table. I will add
> Jonathan Cameron to list if you don't mind, he might give some good
> advice.

I'm not talking about 'PROCESSED' vs 'RAW'...
I'm asking if you can add the 'SCALE' case to handle and report
that this device will report 'processed' temp value in milli-degrees
of Celsius.

> 
>>> +     }
>>> +};
>>> +
>>> +static int gadc_thermal_read_raw(struct iio_dev *indio_dev,
>>> +                              struct iio_chan_spec const *chan,
>>> +                              int *temp, int *val2, long mask)
>>> +{
>>> +     struct gadc_thermal_info *gtinfo = iio_priv(indio_dev);
>>> +     int ret;
>>> +
>>> +     if (mask != IIO_CHAN_INFO_PROCESSED)
>>> +             return -EINVAL;
>>
>> Therefore, here it would need to handle such case as well, when
>> a client is asking about scale.
>>
>>> +
>>> +     ret = gadc_thermal_get_temp(gtinfo->tz_dev, temp);
>>> +     if (ret < 0)
>>> +             return ret;
>>> +
>>> +     *temp /= 1000;
>>
>> IMO we shouldn't cut the precision if it's provided.
>> The user of this would know what to do with the value (when
>> the proper information about scale is also available).
>>
> 
> The it will not fit existing IIO framework and thermal readings will
> be 1000 off. I have had to adjust this since my battery suddenly got
> temperature reading of 23200C which obviously was not true. With
> adjustment temperature will be in 10th of C (yes, odd, I know but it
> is what it is).

Your battery driver should get and check the 'SCALE' info first, then
it will know that the value is in higher resolution than it needs.
Therefore, it can divide the value inside its code.
Your proposed division here is creating a limitation.

You shouldn't force all other drivers to ignore and drop the
available information about milli-degC (which is done in this patch).