devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
To: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org"
	<lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org>
Subject: Re: [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes
Date: Wed, 18 Sep 2013 08:57:32 -0700	[thread overview]
Message-ID: <20130918155732.GA17160@roeck-us.net> (raw)
In-Reply-To: <5239CCAA.7030505-l0cyMroinI0@public.gmane.org>

On Wed, Sep 18, 2013 at 11:54:18AM -0400, Eduardo Valentin wrote:
> On 18-09-2013 11:17, Guenter Roeck wrote:
> > On Wed, Sep 18, 2013 at 10:29:09AM -0400, Eduardo Valentin wrote:
> >> On 18-09-2013 07:18, Guenter Roeck wrote:
> >>> On Tue, Sep 17, 2013 at 06:29:45PM -0400, Eduardo Valentin wrote:
> >>>> On 15-09-2013 19:33, Guenter Roeck wrote:
> >>>>> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
> >>>>>> This patch adds to tmp102 temperature sensor the possibility to
> >>>>>> expose itself as thermal zone device, registered on the thermal
> >>>>>> framework.
> >>>>>>
> >>>>>> The thermal zone is built only if a device tree node describing
> >>>>>> a thermal zone for this sensor is present inside the tmp102 DT
> >>>>>> node. Otherwise, the driver behavior will be the same.
> >>>>>>
> >>>>>> Cc: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org> Cc: Guenter Roeck
> >>>>>> <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> Cc: lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org Cc:
> >>>>>> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Signed-off-by: Eduardo Valentin
> >>>>>> <eduardo.valentin-l0cyMroinI0@public.gmane.org> --- drivers/hwmon/tmp102.c | 28
> >>>>>> ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
> >>>>>>
> >>>>>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c 
> >>>>>> index d7b47ab..e432444 100644 --- a/drivers/hwmon/tmp102.c +++
> >>>>>> b/drivers/hwmon/tmp102.c @@ -27,6 +27,8 @@ #include
> >>>>>> <linux/mutex.h> #include <linux/device.h> #include
> >>>>>> <linux/jiffies.h> +#include <linux/thermal.h> +#include
> >>>>>> <linux/of.h>
> >>>>>>
> >>>>>> #define    DRIVER_NAME "tmp102"
> >>>>>>
> >>>>>> @@ -50,6 +52,7 @@
> >>>>>>
> >>>>>> struct tmp102 { struct device *hwmon_dev; +    struct
> >>>>>> thermal_zone_device *tz; struct mutex lock; u16 config_orig; 
> >>>>>> unsigned long last_update; @@ -93,6 +96,19 @@ static struct
> >>>>>> tmp102 *tmp102_update_device(struct i2c_client *client) return
> >>>>>> tmp102; }
> >>>>>>
> >>>>>> +static int tmp102_read_temp(void *dev, long *temp) +{ +
> >>>>>> struct tmp102 *tmp102 =
> >>>>>> tmp102_update_device(to_i2c_client(dev)); + +    if
> >>>>>> (tmp102->temp[0] < 0) +        dev_warn(tmp102->hwmon_dev, +
> >>>>>> "operating in negative temp: %d\n", tmp102->temp[0]); +
> >>>>>
> >>>>> Please drop this warning.
> >>>>>
> >>>>
> >>>> Done for both drivers.
> >>>>
> >>>>> Guenter
> >>>>>
> >>>>>> +    *temp = tmp102->temp[0]; + +    return 0; +} + static
> >>>>>> ssize_t tmp102_show_temp(struct device *dev, struct
> >>>>>> device_attribute *attr, char *buf) @@ -204,6 +220,16 @@ static
> >>>>>> int tmp102_probe(struct i2c_client *client, goto
> >>>>>> fail_remove_sysfs; }
> >>>>>>
> >>>>>> +    tmp102->tz = thermal_zone_of_sensor_register(&client->dev,
> >>>>>> 0, +                             &client->dev, +
> >>>>>> tmp102_read_temp, NULL); +    if (IS_ERR(tmp102->tz)) { +
> >>>>>> dev_warn(&client->dev, +             "Could not parse thermal
> >>>>>> data in device tree: %ld\n", +
> >>>>>> PTR_ERR(tmp102->tz));
> >>>>>
> >>>>> Please drop this warning. You already create error messages in 
> >>>>> thermal_zone_of_sensor_register(). That should be sufficient. The
> >>>>> same applies to the lm75 patch.
> >>>>
> >>>> OK. Done for both.
> >>>>
> >>>>>
> >>>>> As a side note, I would suggest to provide devm_ functions for 
> >>>>> registration. We are introducing those for hwmon registration,
> >>>>> which enables us to remove most _remove functions. It would be
> >>>>> great if we can keep it that way.
> >>>>>
> >>>>
> >>>> Right. This side note is taken. Actually this is on my todo list
> >>>> for quite a while. But I believe this should not block this series,
> >>>> should it? I will be probably cleaning the thermal framework code
> >>>> after this current work is accepted at least.
> >>>>
> >>>>> On a higher level, I don't think it is a good idea to make
> >>>>> thermal zones and thermal zone data mandatory. Many systems may
> >>>>> neither need nor want it.
> >>>>>
> >>>>
> >>>> Well, I agree with you. Did you see something hard required in the
> >>>> patch I sent. I made it so that it could continue the driver probe
> >>>> without thermal zones, as you requested.
> >>>>
> >>> If it is not mandatory you should not dump an error message to the
> >>> console in the thermal registration function. Since you do, you at
> >>> least consider it mandatory if that function is called.
> >>>
> >>> So please either drop the error message from the registration
> >>> function or add a check into the drivers to only register into the
> >>> thermal subsystem if there is a respective thermal entry for that
> >>> sensor in the devicetree data.
> >>>
> >>> There are systes out there with literally dozens of temperature
> >>> sensors. In many cases, those are purely for system health
> >>> monitoring, not for thermal management. I don't want to end up in a
> >>> situation where users complain about dozens of error messages on the
> >>> console and no way to avoid it but providing dummy thermal subsystem
> >>> data.
> >>>
> >>
> >> Now I see.
> >>
> >>
> >> Then I will rollback to the previous version in which lm sensors were
> >> first probing for thermal properties within their dt node. Something like:
> >> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
> >> index dc96598..cb1c663 100644
> >> --- a/drivers/hwmon/tmp102.c
> >> +++ b/drivers/hwmon/tmp102.c
> >> @@ -216,11 +216,13 @@ static int tmp102_probe(struct i2c_client *client,
> >>                 goto fail_remove_sysfs;
> >>         }
> >>
> >> -       tmp102->tz = thermal_zone_of_sensor_register(&client->dev, 0,
> >> -                                                    &client->dev,
> >> -                                                    tmp102_read_temp,
> >> NULL);
> >> -       if (IS_ERR(tmp102->tz))
> >> -               tmp102->tz = NULL;
> >> +       if ((of_find_property(client->dev.of_node, "#sensor-cells", NULL)) {
> >> +               tmp102->tz =
> >> thermal_zone_of_sensor_register(&client->dev, 0,
> >> +                                                            &client->dev,
> >> +
> >> tmp102_read_temp, NULL);
> >> +               if (IS_ERR(tmp102->tz))
> >> +                       tmp102->tz = NULL;
> >> +       }
> >>
> >>         dev_info(&client->dev, "initialized\n");
> >>
> >>
> >> Does it sound reasonable?
> >>
> > Personally I would prefer if the registration code fails silently.
> > Pushing the above code into each driver is just adding the same code
> > repeatedly all over the place.
> 
> Fair enough. It becomes tedious and just duplicating code. I agree.
> 
> So I will keep the v2 I just sent and remove the annoying error messages
> from of-thermal.c while registering the sensors.
> 
> > 
> > Also, each sensor instance will still result in an error if there
> > is no global "thermal-zones" entry. Checking for that global entry
> > in each driver would be even more excessive, and I just don't like
> > that noisyness.
> > 
> > Also, I think you'll need to create devicetree bindings documents
> > for the two sensors.
> > 
> 
> Why would I? There is only one extra property and that is already
> documented. I think the sensor still falls into the dummy dt node.
> 
I'll leave that up to the devicetree folks to decide.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2013-09-18 15:57 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-15 22:02 [PATCH 00/16] device thermal limits represented in device tree nodes (v3) Eduardo Valentin
     [not found] ` <1379282563-14650-1-git-send-email-eduardo.valentin-l0cyMroinI0@public.gmane.org>
2013-09-15 22:02   ` [PATCH 01/16] drivers: thermal: allow registering without .get_temp Eduardo Valentin
2013-09-15 22:02   ` [PATCH 02/16] drivers: thermal: introduce device tree parser Eduardo Valentin
2013-09-18 16:03     ` [PATCHv2 " Eduardo Valentin
2013-09-18 17:08       ` Guenter Roeck
     [not found]         ` <20130918170840.GA14830-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2013-09-18 18:54           ` Eduardo Valentin
2013-09-18 19:02             ` [PATCHv3 " Eduardo Valentin
2013-09-18 19:11               ` Joe Perches
2013-09-18 19:44                 ` Eduardo Valentin
2013-09-18 19:59                   ` Joe Perches
2013-09-18 20:04                     ` Eduardo Valentin
2013-09-15 22:02   ` [PATCH 07/16] thermal: ti-soc-thermal: use thermal DT infrastructure Eduardo Valentin
2013-09-15 22:02 ` [PATCH 03/16] drivers: thermal: cpu_cooling: introduce of_cpufreq_cooling_register Eduardo Valentin
2013-09-15 22:02 ` [PATCH 04/16] cpufreq: cpufreq-cpu0: add dt node parsing for cooling device properties Eduardo Valentin
2013-09-15 22:02 ` [PATCH 05/16] hwmon: lm75: expose to thermal fw via DT nodes Eduardo Valentin
     [not found]   ` <1379282563-14650-6-git-send-email-eduardo.valentin-l0cyMroinI0@public.gmane.org>
2013-09-15 23:22     ` Guenter Roeck
     [not found]       ` <5236411E.6040204-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2013-09-17 22:35         ` [PATCHv2 " Eduardo Valentin
2013-09-18 16:21           ` [PATCHv3 " Eduardo Valentin
2013-09-21 18:06             ` Guenter Roeck
2013-09-21 23:30               ` Eduardo Valentin
     [not found]                 ` <523E2C1B.9010307-l0cyMroinI0@public.gmane.org>
2013-09-21 23:56                   ` Guenter Roeck
2013-09-22  0:23                     ` Eduardo Valentin
     [not found]                       ` <523E388F.80707-l0cyMroinI0@public.gmane.org>
2013-09-22  2:24                         ` Guenter Roeck
2013-09-15 22:02 ` [PATCH 06/16] hwmon: tmp102: " Eduardo Valentin
     [not found]   ` <1379282563-14650-7-git-send-email-eduardo.valentin-l0cyMroinI0@public.gmane.org>
2013-09-15 23:33     ` Guenter Roeck
     [not found]       ` <523643D4.30208-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2013-09-17 22:29         ` Eduardo Valentin
     [not found]           ` <20130918111849.GA9148@roeck-us.net>
     [not found]             ` <20130918111849.GA9148-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2013-09-18 14:29               ` Eduardo Valentin
     [not found]                 ` <5239B8B5.6050702-l0cyMroinI0@public.gmane.org>
2013-09-18 15:17                   ` Guenter Roeck
     [not found]                     ` <20130918151746.GA17065-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2013-09-18 15:54                       ` Eduardo Valentin
     [not found]                         ` <5239CCAA.7030505-l0cyMroinI0@public.gmane.org>
2013-09-18 15:57                           ` Guenter Roeck [this message]
     [not found]                             ` <20130918155732.GA17160-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2013-09-18 16:23                               ` Eduardo Valentin
     [not found]                                 ` <5239D383.50009-l0cyMroinI0@public.gmane.org>
2013-09-18 17:08                                   ` Guenter Roeck
2013-09-17 22:34         ` [PATCHv2 " Eduardo Valentin
     [not found]           ` <1379457245-17810-1-git-send-email-eduardo.valentin-l0cyMroinI0@public.gmane.org>
2013-09-18 11:06             ` Guenter Roeck
     [not found]               ` <20130918110649.GA9050-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2013-09-18 14:17                 ` Eduardo Valentin
2013-09-18 16:23           ` [PATCH " Eduardo Valentin
     [not found]             ` <1379521390-17404-1-git-send-email-eduardo.valentin-l0cyMroinI0@public.gmane.org>
2013-09-21 18:07               ` Guenter Roeck
2013-09-15 22:02 ` [PATCH 08/16] arm: dts: add omap4 CPU thermal data Eduardo Valentin
2013-09-15 22:02 ` [PATCH 09/16] arm: dts: add omap4430 " Eduardo Valentin
2013-09-15 22:02 ` [PATCH 10/16] arm: dts: add omap4460 " Eduardo Valentin
2013-09-15 22:02 ` [PATCH 11/16] arm: dts: add cooling properties on omap4430 cpu node Eduardo Valentin
2013-09-15 22:02 ` [PATCH 12/16] arm: dts: add cooling properties on omap4460 " Eduardo Valentin
2013-09-15 22:02 ` [PATCH 13/16] arm: dts: add omap5 GPU thermal data Eduardo Valentin
2013-09-15 22:02 ` [PATCH 14/16] arm: dts: add omap5 CORE " Eduardo Valentin
2013-09-15 22:02 ` [PATCH 15/16] arm: dts: add omap5 " Eduardo Valentin
2013-09-15 22:02 ` [PATCH 16/16] arm: dts: add cooling properties on omap5 cpu node 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=20130918155732.GA17160@roeck-us.net \
    --to=linux-0h96xk9xttrk1umjsbkqmq@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=eduardo.valentin-l0cyMroinI0@public.gmane.org \
    --cc=lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.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 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).