From: Hans de Goede <j.w.r.degoede@hhs.nl>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] add AMDSI PECI sensortype support to
Date: Sun, 08 Jul 2007 19:01:36 +0000 [thread overview]
Message-ID: <46913490.9040508@hhs.nl> (raw)
In-Reply-To: <20070707170959.63922c3e@hyperion.delvare>
Jean Delvare wrote:
> Hi Hans,
>
> On Sat, 07 Jul 2007 21:23:40 +0200, Hans de Goede wrote:
>> Jean Delvare wrote:
>>> The sensors3 patch should be pretty easy, maybe you could take care of
>>> it? It's needed anyway, whether my kernel patch gets applied or not.
>> Ok, here is a proposal:
>>
>> Index: prog/sensors/chips_generic.c
>> =================================>> --- prog/sensors/chips_generic.c (revision 4566)
>> +++ prog/sensors/chips_generic.c (working copy)
>> @@ -209,6 +209,11 @@
>> /* print out temperature sensor info */
>> if (TEMP_FEATURE(SENSORS_FEATURE_TEMP_SENS)) {
>> int sens = (int)TEMP_FEATURE_VAL(SENSORS_FEATURE_TEMP_SENS);
>> +
>> + /* older kernels / drivers sometimes report a beta value for thermistors */
>> + if (sens > 1000)
>> + sens = 4;
>> +
>> printf("sensor = %s", sens = 0 ? "disabled" :
>> sens = 1 ? "diode" :
>> sens = 2 ? "transistor" :
>>
>> The idea here is that a beta value should (reasonably) always be > 1000, and we
>> don't want to assume thermistor for any unknown value as we might add new types
>> to the list later. Does this look ok?
>
> Yes, that's fine with me.
>
committed
>>> I'm still not sure which minimum version we want to support. I don't
>>> want to support anything older than 2.6.5 for sure, things were just
>>> too badly broken before that. And I don't want to clutter the
>>> libsensors code too much to deal with the non-standard things that some
>>> old kernels had. Unless someone has a better plan, I think we'll make
>>> things work for the systems we developers are using, and release that,
>>> and then if users complain that it doesn't work with some older kernel
>>> they're using, we'll consider adding support on a case-by-case basis,
>>> depending on how intrusive that would be.
>> That sounds like a plan, but not like something one would put in a README,
>> which then brings me to the question what do we put in the readme, just that it
>> requires a kernel > 2.6.5, or maybe we should require one which has the hwmon
>> class?
>
> Well, requiring the hwmon class would let us cleanup a number of things
> for sure, so it may be a good idea. That would mean we "only" support
> kernels >= 2.6.14. But even then, the README will have to mention that
> some features are not available before much more recent kernels. Most
> notably, the alarms for most devices won't be available before 2.6.24.
>
2.6.14 sounds ok as a base, most people shoild be using something newer then
that by now.
Regards,
Hans
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
prev parent reply other threads:[~2007-07-08 19:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-07 15:09 [lm-sensors] add AMDSI PECI sensortype support to Jean Delvare
2007-07-07 19:15 ` Jean Delvare
2007-07-07 19:23 ` Hans de Goede
2007-07-08 18:56 ` Jean Delvare
2007-07-08 19:01 ` Hans de Goede [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46913490.9040508@hhs.nl \
--to=j.w.r.degoede@hhs.nl \
--cc=lm-sensors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.