linux-kernel - Re: 回复: Re: [PATCH v1] hwmon: (scpi-hwmon) shows the negative temperature properly

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>] [day] [month] [year] [list]

Date:   Mon, 24 May 2021 07:03:13 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     卢日文 <luriwen@...inos.cn>, jdelvare@...e.com
Cc:     linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org,
        Xin Chen <chenxin@...inos.cn>
Subject: Re: 回复: Re: [PATCH v1] hwmon: (scpi-hwmon) shows the negative temperature properly

On 5/23/21 6:48 PM, 卢日文 wrote:
>  > What did you test ? Did you really manage to run the system
>  > in such an environment ?
> 
>  > 'value' is declared as u64, not as s64.
>  > I can not evaluate what the firmware actually reports. The API
>  > reports an u64. Do you have any evidence for your claim that
>  > it returns a signed value under any circumstances ?
> 
> 
> Yes, the comsumer of my company test their machines in harsh environment including the very low temperature.
> 
I tried to look this up, but the ARM developer documentation is vague when
it comes to describing the content of sensor readings. Is it documented
somewhere that the temperature is actually returned as signed value ?
If so, can you point me to it ?

I'll need to have some confirmation that this is legitimate.

> The first picture below shows that the temp returned as a unsigned value when it is a negtive value with sensors tool.
> 
> And the second picture shows the real value after applyed my changes in scpi hwmon.
> 
> 1234.jpg
> 
> 2345.jpg
> 
Pictures are not attached.

> 
>  > On top of that, your change affects not only temperature values,
>  > but all attributes. It is highly unlikely that the firmware would
>  > report negative power or energy values. It is, however, possible
>  > that energy values have the upper bit of an u64 set after a
>  > long runtime. Your change would result in a negative energy value
>  > if that is ever the case.
> 
> 
> Sorry for not considered this situation before.
> 
> But I think it can be judged by sensor->info.class. if it is TEMPERATURE situation, return the value as a signed value,  otherwise it returned as a unsigned value.
> 
Correct.

Thanks,
Guenter