From: Eduardo Valentin <edubezval@gmail.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Zhang Rui <rui.zhang@intel.com>, Jean Delvare <jdelvare@suse.com>,
ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TECH TOPIC] [CORE TOPIC] The three ways of temperature sensing in Linux
Date: Tue, 25 Aug 2015 17:12:31 -0700 [thread overview]
Message-ID: <20150826001229.GE5772@localhost.localdomain> (raw)
In-Reply-To: <20150825235518.GA31163@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]
On Tue, Aug 25, 2015 at 04:55:18PM -0700, Guenter Roeck wrote:
> On Tue, Aug 25, 2015 at 11:31:46PM +0200, Heiko Stuebner wrote:
> >
> > So far I always thought hwmon was some sort of grandfather to the thermal
> > subsystem without any specific api, but I've also not needed one at all yet.
> >
> Yes, I have heard that before.
And that is a misconception, I would say, as both have different design
goals. Keep in mind that my original proposal is to discuss what touches
the monitoring part.
>
> Its scope is quite different, though. One does thermal management, one monitors
> the hardware. Monitoring the hardware is a bit more than just monitoring its
> temperature. It also means to monitor and report voltages, current, power,
> energy, humidity, and fan speeds, as well as associated alarms. Thermal
> management takes an active role, hardware monitoring by its nature doesn't.
I agree here. Also, keep in mind that the scope of thermal subsystem is
not only monitor temperature, but also cover what needs to be done when
the system state changes and needs action, typically on top of
temperature thresholds/trip points.
>
> On top of that, many devices report much more than temperatures.
> System managers may report and sometimes control all of the above. SuperIO
> chips monitor voltages, temperatures, and fan speeds, and often implement fan
> control. PMBus devices primarily control voltages, but may report literally
> everything except for humidity (including fan speeds). And so on.
There are discussions to have power / voltage / current (and humidity
too) inputs to the thermal subsystem. And that's probably where the issue
gets worse. Another take we could have is to centralize the hw monitoring
part of the problem in, well, hwmon, and make thermal a user of it. Then
we would move the thermal drivers, at least the sensing part of
them, to hwmon. But then again, we still have the IIO case :-).
BR,
Eduardo Valentin
>
> Maybe just have a look into drivers/hwmon/pmbus/ltc2978.c, and let me know
> where you would like to have this driver (and all the other PMBus drivers)
> moved to.
>
> Thanks,
> Guenter
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2015-08-26 0:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-25 6:12 Eduardo Valentin
2015-08-25 6:26 ` Krzysztof Kozlowski
2015-08-25 14:03 ` Guenter Roeck
2015-08-25 21:26 ` Eduardo Valentin
2015-08-25 21:13 ` Eduardo Valentin
2015-08-25 21:31 ` Heiko Stuebner
2015-08-25 23:55 ` Guenter Roeck
2015-08-26 0:12 ` Eduardo Valentin [this message]
2015-08-26 4:14 ` Guenter Roeck
2015-08-26 6:04 ` Jonathan Cameron
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=20150826001229.GE5772@localhost.localdomain \
--to=edubezval@gmail.com \
--cc=jdelvare@suse.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=linux@roeck-us.net \
--cc=rui.zhang@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox