From: Javi Merino <javi.merino@arm.com>
To: Eduardo Valentin <edubezval@gmail.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
rui.zang@intel.com, Zhang Rui <rui.zhang@intel.com>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH v3 2/4] devicetree: bindings: let thermal-sensor point to other thermal zones
Date: Mon, 21 Mar 2016 11:55:11 +0000 [thread overview]
Message-ID: <20160321115511.GA6590@e104805> (raw)
In-Reply-To: <20160303032152.GD3379@localhost.localdomain>
On Wed, Mar 02, 2016 at 07:21:53PM -0800, Eduardo Valentin wrote:
> On Mon, Jan 04, 2016 at 03:17:09PM +0100, Sascha Hauer wrote:
> > On Wed, Nov 25, 2015 at 03:09:44PM +0000, Javi Merino wrote:
> > > The thermal-sensor property of the thermal zone node accepts phandles to
> > > thermal sensors. However, thermal zones can be created as an
> > > +
> > > + thermal-sensors = <&cpu_thermal &gpu_thermal &lcd_thermal>
> >
> > This seems inconsistent. Why can a thermal zone only have multiple
> > thermal sensors when they are thermal zones themselves? Either we assume
> > that one thermal zone has a single sensor or we assume that it can have
> > multiple sensors, but this should not depend on the zone being a sub zone
> > or not.
> >
> > I think the thermal-sensors property should always point to one or
> > multiple sensors. I see no point in "This property either points to
> > exactly one sensor or multiple other thermal zones (from which we only
> > use the temperature)"
>
>
> Agreed here. In fact, if we are going to allow thermal zones to be
> treated as sensors, it means there should be no limits on what you put
> of there, as long as all items have #thermal-sensor-cells. So, mixing
> one (or more) regular sensors, with other thermal zones shall be
> allowed, if we agree in this semantics.
Eduardo, thanks for the review. There doesn't seem to be much
interest in this and I currently have no time to work on it so I am
dropping this series for the time being. I'm happy for this to be
picked up by somebody else (or who knows, maybe I will be able to work
on it again in the future).
Javi
next prev parent reply other threads:[~2016-03-21 11:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1448464186-26289-1-git-send-email-javi.merino@arm.com>
2015-11-25 15:09 ` [PATCH v3 2/4] devicetree: bindings: let thermal-sensor point to other thermal zones Javi Merino
2015-11-25 17:54 ` Mark Rutland
2015-11-25 18:41 ` Javi Merino
2016-01-04 14:17 ` Sascha Hauer
2016-03-03 3:21 ` Eduardo Valentin
2016-03-21 11:55 ` Javi Merino [this message]
2016-03-22 15:13 ` Eduardo Valentin
2016-03-03 3:19 ` Eduardo Valentin
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=20160321115511.GA6590@e104805 \
--to=javi.merino@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=edubezval@gmail.com \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=rui.zang@intel.com \
--cc=rui.zhang@intel.com \
--cc=s.hauer@pengutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).