linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wei Ni <wni@nvidia.com>
To: Jean Delvare <khali@linux-fr.org>,
	"rui.zhang@intel.com" <rui.zhang@intel.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v3 1/4] hwmon: (lm90) split set&show temp as common codes
Date: Mon, 15 Jul 2013 17:14:07 +0800	[thread overview]
Message-ID: <51E3BD5F.6060806@nvidia.com> (raw)
In-Reply-To: <20130715092415.6d082aa2@endymion.delvare>

On 07/15/2013 03:24 PM, Jean Delvare wrote:
> On Mon, 15 Jul 2013 14:25:29 +0800, Wei Ni wrote:
>> On 07/12/2013 10:40 PM, Guenter Roeck wrote:
>>> On Fri, Jul 12, 2013 at 04:30:34PM +0200, Jean Delvare wrote:
>>>> If that means that for example the ACPI thermal zone is no longer
>>>> displayed by "sensors", then I strongly object - unless it is
>>>> explicitly registered as a separate hwmon device from now on, of course.
>>>
>>> If I recall correctly that was the idea. Of course, in practice that will mean
>>> that devices will _not_ get exposed as hwmon devices, as implementers won't
>>> bother doing both.
>>>
>>>> My idea was to make the bridge optional - you decide when you register
>>>> a thermal device if it should be exposed as hwmon or not.
>>>
>>> Yes, that would be a much better solution.
>>
>> I think we can decide it in the DT, we can add a dt property in the lm90
>> device node, such as:
>> sys-interface = SYS_HWMON;
>> or
>> sys-interface = SYS_THERMAL;
>> So we register it as the hwmon or thermal device
> 
> This is an option, but please keep in mind that DT is not the only way
> to instantiate LM90-like devices, and we should not expose duplicate
> inputs by default. It is fine with me if the default is to create only a
> HWMON device (as the lm90 driver was doing so far), and only
> DT-instantiated devices have the choice.

Yes, we should not expose duplicate inputs, we may have tree permutation:
1. only hwmon device:
for this items, we just need to call hwmon_device_register().
2. only thermal device + virtual hwmon device:
for this items, we just need to call thermal_zone_device_register().

We can set #1 as the default, and if use DT, we provide option to choice
#1 or #2.

3. hwmon device + thermal device:
for this items, we doesn't need the virtual hwmon which registered by
the thermal fw, how to handle this one? Add flag when register as
thermal device to indicate if want virtual hwmon device or not,
something like your below another option.

> 
> Another option, as discussed before, would be that the thermal devices
> registered by lm90 are specifically tagged as "do not expose as hwmon".
> This would avoid the duplicate hwmon inputs in all cases.

It seems in current thermal fw, it can't be tagged as "do not expose as
hwmon", we need to add flag when register thermal device.

Rui, what do you think for it?

> 
> Again - no strong opinion on the implementation, as long as it does the
> right thing.

I'm working on the Tegra platform, we uses nct1008 as the temperature
sensor, and we want to register it as thermal device, so that we can run
the throttle function. So I prepared these patches to enhance this driver.

> 
> Oh, and we'll have to be careful with the Kconfig dependencies. I do
> not want the lm90 driver to depend on the thermal framework.

Yes, absolutely agree, lm90 should be independent.
Indeed, the thermal folks is trying to restructure the thermal fw, and
in this new fw, it's more easy to add the generic sensors to the thermal
fw. If you interest it, please refer
http://thread.gmane.org/gmane.linux.power-management.general/30692.

Thanks.
Wei.

> 


  reply	other threads:[~2013-07-15  9:15 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-12  7:48 [PATCH v3 0/4] Lm90 Enhancements Wei Ni
2013-07-12  7:48 ` [PATCH v3 1/4] hwmon: (lm90) split set&show temp as common codes Wei Ni
2013-07-12 13:26   ` Jean Delvare
2013-07-12 13:50     ` Guenter Roeck
2013-07-12 14:30       ` Jean Delvare
2013-07-12 14:40         ` Guenter Roeck
2013-07-15  6:25           ` Wei Ni
2013-07-15  7:24             ` Jean Delvare
2013-07-15  9:14               ` Wei Ni [this message]
2013-07-15 17:52                 ` Jean Delvare
2013-07-17  4:26               ` Thierry Reding
2013-07-17  5:14                 ` Guenter Roeck
2013-07-17  6:26                   ` Wei Ni
2013-07-17  9:11                     ` Jean Delvare
2013-07-17  9:54                       ` Wei Ni
2013-07-15  6:05     ` Wei Ni
2013-07-15  7:29       ` Jean Delvare
2013-07-12  7:48 ` [PATCH v3 2/4] hwmon: (lm90) use macro defines for the status bit Wei Ni
2013-07-15 16:57   ` Jean Delvare
2013-07-15 17:33     ` Guenter Roeck
2013-10-30 15:33       ` Jean Delvare
2013-10-30 16:11         ` Guenter Roeck
2013-10-30 16:56         ` Guenter Roeck
2013-07-17  7:03     ` Wei Ni
2013-07-17  7:09       ` Wei Ni
2013-07-17  8:28       ` Jean Delvare
2013-07-17  9:29         ` Wei Ni
2013-07-17  9:46           ` Jean Delvare
2013-07-12  7:48 ` [PATCH v3 3/4] hwmon: (lm90) add support to handle IRQ Wei Ni
2013-07-18 15:58   ` Jean Delvare
2013-07-19  6:41     ` Wei Ni
2013-07-24  7:46       ` Wei Ni
2013-07-24  8:08         ` Jean Delvare
2013-07-27 15:02       ` Jean Delvare
2013-07-29 10:14         ` Wei Ni
2013-07-29 15:58           ` Jean Delvare
2013-07-30  8:18             ` Wei Ni
2013-09-16 12:34               ` Jean Delvare
2013-07-12  7:48 ` [PATCH v3 4/4] hwmon: (lm90) use enums for the indexes of temp8 and temp11 Wei Ni
2013-07-27 15:38   ` Jean Delvare
2013-07-29 11:15     ` Wei Ni
2013-07-29 15:48       ` Jean Delvare
2014-08-25  6:29 [PATCH v3 0/4] expose lm90 to thermal fw Wei Ni
2014-08-25  6:29 ` [PATCH v3 1/4] hwmon: (lm90) split set&show temp as common codes Wei Ni
2014-08-25 12:23   ` Mikko Perttunen
2014-08-26  2:27     ` Wei Ni
2014-08-26 12:17       ` Eduardo Valentin
2014-08-26 16:37         ` Stephen Warren
2014-08-27  2:25           ` Wei Ni

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=51E3BD5F.6060806@nvidia.com \
    --to=wni@nvidia.com \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lm-sensors@lm-sensors.org \
    --cc=rui.zhang@intel.com \
    --cc=thierry.reding@gmail.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;
as well as URLs for NNTP newsgroup(s).