[lm-sensors] add AMDSI PECI sensortype support to generic_temp_print
Hans de Goede
j.w.r.degoede at hhs.nl
Sat Jul 7 17:45:36 CEST 2007
Jean Delvare wrote:
> On Thu, 5 Jul 2007 13:23:04 +0200 (CEST), lm-sensors-notify at lm-sensors.org wrote:
>> Author: jwrdegoede
>> Date: Thu Jul 5 13:22:57 2007
>> New Revision: 4552
>> Changeset: http://lm-sensors.org/changeset/4552
>> add AMDSI PECI sensortype support to generic_temp_print()
> Good catch, but this does not yet cover all the values listed in
> temp[1-*]_type Sensor type selection.
> Integers 1 to 6 or thermistor Beta value (typically 3435)
> 1: PII/Celeron Diode
> 2: 3904 transistor
> 3: thermal diode
> 4: thermistor (default/unknown Beta)
> 5: AMD AMDSI
> 6: Intel PECI
> Not all types are supported by all chips
> Notice the "or thermistor Beta value". The w83627hf and w83781d drivers
> actually export 3435 and not just 4 for thermistors, so the new
> "sensors", in its current state, won't work for them. We could make it
> default to "thermistor" for unknown or arbitrarily large values. But
> OTOH, this feature (exporting the beta value) doesn't seem terribly
> useful. In the two drivers which export the beta value... this value is
> hard-coded in the driver, and not used anywhere, so what's the point?
> Thus I think that this is also the right time to get rid of this old
> convention, and start using always value 4 for thermistors. The upgrade
> plan would be:
> * Update Documentation/hwmon/sysfs-interface to no longer mention
> beta values, and change the w83781d and w83627hf drivers to export
> a thermal sensor value of 4 instead of 3435 for thermistors. We may
> want to still accept when 3435 is written to the tempN_type files for
> backwards compatibility for now, and drop support for it only later.
> Proposed patch attached.
> * Update sensors (v3) to still expect a thermal type value of 3435, and
> treat it as value 4. We want it to work OK with the drivers from
> previous 2.6 kernels.
> * Update sensors.conf.eg to mention this change.
> The good news is that the old "sensors" already defaults to
> "thermistor" for unknown values for w83781d and w83627hf, so it won't
> be affected by the change. Hopefully, other applications using
> libsensors either do the same, or use generic code to display the
> thermal types, of don't report thermal types at all.
> Objection anyone?
Your proposal sounds good, and the patches look good. I didn't see a patch for
sensors3 to recognise the old 3435 value though, whichbring us to the queston
what will be the minimum kernel version we want to support with 3.0.0.
More information about the lm-sensors