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: <CAPVz0n0yvw4kyYKSve9sSZEvcZrCYZ6RqCjFSO5OCqtvRZSfJg@mail.gmail.com>
Date: Wed, 5 Mar 2025 12:06:42 +0200
From: Svyatoslav Ryhel <clamor95@...il.com>
To: Lukasz Luba <lukasz.luba@....com>, Jonathan Cameron <jic23@...nel.org>
Cc: linux-pm@...r.kernel.org, devicetree@...r.kernel.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

ср, 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.

> > +     }
> > +};
> > +
> > +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).

> > +
> > +     return IIO_VAL_INT;