linux-kernel - Re: [PATCH v3] k10temp: temperature sensor for AMD Family 10h/11h CPUs

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 24 Nov 2009 15:09:57 +0100
From:	Clemens Ladisch <clemens@...isch.de>
To:	Jean Delvare <khali@...ux-fr.org>
CC:	Serge Belyshev <belyshev@...ni.sinp.msu.ru>,
	linux-kernel@...r.kernel.org, lm-sensors@...sensors.org
Subject: Re: [PATCH v3] k10temp: temperature sensor for AMD Family 10h/11h
 CPUs

Jean Delvare wrote:
> On Tue, 24 Nov 2009 09:43:29 +0100, Clemens Ladisch wrote:
> > In any case, it might make more sense to show such values as something
> > like "20 °C below maximum".
> 
> I think so, yes. Now the difficulty is to come up with a suitable sysfs
> interface. Dropping the current interface altogether doesn't sound
> right as it will take time before a new version of libsensors is
> written and spread out and all applications add support for the new
> interface. In the meantime, I guess we want users to still see the
> approximate value.

k10temp is a new driver, so no old systems would break if it introduced
a new class of measurements with names like, e.g., reltemp#_*.
We could add this in parallel with the old interface.  If we wanted to.

> So ideally we would come up with an interface that adds up to the one
> we have currently. Future libsensors/applications could read the extra
> information to display the value in a different format so that the
> users see the difference.
> 
> An idea I have about this is adding a sysfs file temp#_relative, which
> would contain the fake temperature value that is used as a reference
> for the thermal sensor in question. In the case of k10temp, the value
> would be 70000. So for example we would have:
> 
> temp1_input: 46000
> temp1_relative: 70000
> 
> Old applications would display this as 46°C while new ones would
> display "24°C below the limit".

In this case, temp1_relative is identical with temp1_max.  In the
general case, there always must be some kind of limit (whether "max" or
"crit" or something else) against which the values are measured,
otherwise a relative value would not make sense.

This means that one of the already existing limit values must be the
reference base, so we'd need just a mechanism to specify which of them
is it, i.e., "temp1_relative_base: max".  If we'd have
"temp1_relative: 70000", the application would have to search among the
limit values for one with the same value.

(It doesn't really matter which one is the base, as all values are
relative anyway, so we could just define that temp#_max is the base;
so we'd have "temp1_relative: true").

> It may not be considered flexible enough though... For example it does
> not support sensors with totally arbitrary scales (where 1000 != 1°C.)

When the scale differs but is _known_, the driver can just rescale its
internal register values to millidegrees.

When we have some scale like "0%...100%", that should probably be
exported as "pwm#_target" or something like that.

Best regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/