mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Eduardo Valentin <eduardo.valentin@ti.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <rob.herring@calxeda.com>,
	devicetree-discuss@lists.ozlabs.org, wni@nvidia.com,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	lm-sensors@lm-sensors.org, l.stach@pengutronix.de
Subject: Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
Date: Thu, 18 Jul 2013 11:18:05 -0600	[thread overview]
Message-ID: <51E8234D.1020607@wwwdotorg.org> (raw)
In-Reply-To: <51E7F341.8020508@ti.com>

On 07/18/2013 07:53 AM, Eduardo Valentin wrote:
> Hello Guenter,
> 
> On 17-07-2013 18:09, Guenter Roeck wrote:
>> On Wed, Jul 17, 2013 at 11:17:19AM -0400, Eduardo Valentin
>> wrote:
>>> Hello all,
>>> 
>>> As you noticed, I am working in a way to represent thermal
>>> data using device tree [1]. Essentially, this should be a way
>>> to say what to do with a sensor and how to associate (cooling)
>>> actions with it.
>>> 
>> Seems to me that goes way beyond the supposed scope of devicetree
>> data. Devicetree data is supposed to describe hardware, not its
>> configuration or use. This is clearly a use case.
> 
> Thanks for rising your voice here. It is important to know what
> hwmon ppl think about this.

I meant to find time to read Guenter's original email where he
initially objected to putting data into DT, and determine exactly what
was being objected to. I still haven't:-( However, the arguments that
Eduardo stated in his email do make sense to me; I agree that
temperature limits really are a description of HW. Details of which
cooling methods to invoke when certain temperature limits are reached
is also part of the HW/system design, and hence I would tend to agree
that they're appropriate to include in DT. Anyway, that's just my 2
cents on the matter:-)

  reply	other threads:[~2013-07-18 17:18 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-17 15:17 Eduardo Valentin
2013-07-17 15:17 ` [RESEND PATCH V1 1/9] cpufreq: cpufreq-cpu0: add dt node parsing for 'needs-cooling' Eduardo Valentin
2013-07-25 23:28   ` Rafael J. Wysocki
2013-07-26 13:27     ` Eduardo Valentin
2013-07-17 15:17 ` [RESEND PATCH V1 2/9] thermal: hwmon: move hwmon support to single file Eduardo Valentin
2013-07-17 16:29   ` [lm-sensors] " R, Durgadoss
2013-07-17 15:17 ` [RESEND PATCH V1 3/9] thermal: thermal_core: allow binding with limits on bind_params Eduardo Valentin
2013-07-17 16:25   ` [lm-sensors] " R, Durgadoss
2013-07-17 15:17 ` [RESEND PATCH V1 4/9] arm: dts: flag omap4430 with needs-cooling for cpu node Eduardo Valentin
2013-07-17 15:17 ` [RESEND PATCH V1 5/9] thermal: introduce device tree parser Eduardo Valentin
2013-07-17 15:17 ` [RESEND PATCH V1 6/9] thermal: ti-soc-thermal: use thermal DT infrastructure Eduardo Valentin
2013-07-17 15:17 ` [RESEND PATCH V1 7/9] arm: dts: add omap4430 thermal data Eduardo Valentin
2013-07-17 15:17 ` [RESEND PATCH V1 8/9] hwmon: lm75: expose to thermal fw via DT nodes Eduardo Valentin
2013-07-18  5:33   ` Wei Ni
2013-07-18 13:12     ` Eduardo Valentin
2013-07-19  7:43       ` Wei Ni
2013-07-18  7:22   ` Guenter Roeck
2013-07-17 15:17 ` [RESEND PATCH V1 9/9] hwmon: tmp102: " Eduardo Valentin
2013-07-18  7:23   ` Guenter Roeck
2013-07-17 22:09 ` [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build Guenter Roeck
2013-07-18 13:53   ` Eduardo Valentin
2013-07-18 17:18     ` Stephen Warren [this message]
2013-07-18 21:21       ` Guenter Roeck
2013-07-19 13:03         ` Eduardo Valentin
2013-07-19 18:48         ` Stephen Warren
2013-07-21 11:08           ` Guenter Roeck
2013-07-22 19:43             ` Stephen Warren
2013-07-22 21:46               ` Guenter Roeck
2013-07-18 21:11     ` Guenter Roeck
2013-07-19 13:38       ` Eduardo Valentin
2013-07-19 18:45         ` Stephen Warren
2013-07-19 18:56           ` Eduardo Valentin
2013-07-21 10:14             ` Guenter Roeck

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=51E8234D.1020607@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=eduardo.valentin@ti.com \
    --cc=grant.likely@linaro.org \
    --cc=l.stach@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lm-sensors@lm-sensors.org \
    --cc=rob.herring@calxeda.com \
    --cc=wni@nvidia.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

Powered by JetHome