linux-kernel - Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <51ED8B6F.6020700@wwwdotorg.org>
Date:	Mon, 22 Jul 2013 12:43:43 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Guenter Roeck <linux@...ck-us.net>
CC:	Eduardo Valentin <eduardo.valentin@...com>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <rob.herring@...xeda.com>,
	devicetree-discuss@...ts.ozlabs.org, wni@...dia.com,
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
	lm-sensors@...sensors.org, l.stach@...gutronix.de
Subject: Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal
 zone build

On 07/21/2013 04:08 AM, Guenter Roeck wrote:
> ... [a bunch of good points re: why DT shouldn't describe thermal
> profiles]

Yes, lots of good arguments there.

So, where/how in your opinion should thermal profiles be defined, and
how should they get into the kernel? The nice thing about DT is that
it's a single place that describes the platform, with a well-defined
method of getting that information into the kernel. What alternatives exist?

> Other but related subject .. from a thermal / hwmon driver's perspective, if
> such a driver supports thermal subsystem, it should just register itself as
> thermal sensor device, because that is what it is. If and how it is tied to
> cooling devices should be part of the thermal subsystem and be decided there.

For audio, we have individual DT nodes that represent individual
audio-related components such as audio controllers, audio CODECs, etc.
We also have a "virtual" node that describes how those components
interact and create a complete sound card. Would it make sense to do
something similar with thermal sensors and cooling devices; represent
them all individually, have them register themselves with the
thermal/hwmon subsystem as you describe, but then have another "system
level" node that describes how the system designer intended them to
interact?

If you don't think so, how would the kernel represent and gain that
higher-level knowledge?
--
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/