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] [day] [month] [year] [list]
Message-ID: <67659d9d-f228-42ac-b096-01020bf66b7f@arm.com>
Date: Thu, 6 Mar 2025 10:04:01 +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/6/25 09:49, Svyatoslav Ryhel wrote:
> ср, 5 бер. 2025 р. о 16:37 Lukasz Luba <lukasz.luba@....com> пише:
>>
>>
>>
>> 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.
>>
> 
> It seems that SCALE is not applied to PROCESSED channel. I can use RAW
> which would work as intended and I will add a note in commit
> description why I used RAW. Would that be acceptable?
> 

In that case, yes that would be the preferred solution.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ