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
