linux-hwmon.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jean-Francois Dagenais <jeff.dagenais@gmail.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org, jdelvare@suse.com
Subject: Re: [PATCH v2] hwmon: max6650: add thermal cooling device capability
Date: Thu, 18 Apr 2019 15:54:32 -0400	[thread overview]
Message-ID: <40DEF6F9-FA5B-4537-BD02-6763D7C885A1@gmail.com> (raw)
In-Reply-To: <20190418180623.GA18588@roeck-us.net>



> On Apr 18, 2019, at 14:06, Guenter Roeck <linux@roeck-us.net> wrote:
> 
> On Thu, Apr 18, 2019 at 02:02:48PM -0400, Jean-Francois Dagenais wrote:
>> 
>>> On Apr 18, 2019, at 13:38, Guenter Roeck <linux@roeck-us.net> wrote:
>>> 
>>>> +#if IS_ENABLED(CONFIG_THERMAL)
>>> 
>>> This will result in missing symbols if THERMAL is built as module
>>> and this driver is built into the kernel. You'll have to adjust
>>> Kconfig dependencies accordingly. See other drivers for examples.
>> 
>> Right! Was not a problem for me, but I do remember seing the "funny"
>> ifdefs around.
>> 
> 
> I know, it is annoying. There was an effort to make THERMAL boolean
> instead of tristate, but it looks like that has stalled or was
> rejected.

Ok, so I had used pwm-fan.c as a reference and simply forgotten to copy over the
Kconfig bit which makes sure if the thermal is a module, then so is the chip
driver. I will put in v3.

> 
>>> 
>>>> +	data->cooling_dev =
>>>> +		thermal_of_cooling_device_register(client->dev.of_node,
>>>> +						   id->name, data,
>>>> +						   &max6650_cooling_ops);
>>>> +	if (IS_ERR(data->cooling_dev)) {
>>>> +		err = PTR_ERR(data->cooling_dev);
>>>> +		dev_err(&client->dev,
>>>> +			"Failed to register as cooling device (%d)\n", err);
>>>> +		return err;
>>> 
>>> Why would it be fatal for the driver if this fails ? It wasn't
>>> fatal before.
>> 
>> Mmmh, you are right. This assumes that all users of max6650 would now require to
>> be referred to in some thermal zone. Again, this was not a problem for my test
>> environment.

And about this bit... I had confused the thermal cooling register with the
thermal_of_sensor register. So if my static analysis of the code in
__thermal_cooling_device_register is correct, the function cannot really fail
unless something is terribly wrong in the kernel... like a malloc failure or
something.

If I am wrong, then pwm-fan.c should also be visited since my max6650_probe code
was copy-pasted from it.


On a related note, I am worried about everyone having to progressively add
thermal-zone support to each fan chip in drivers/hwmon. Would it not be possible
for hwmon to detect, through `enum hwmon_sensor_types` set to `hwmon_fan` in
`struct hwmon_channel_info` to be registered as cooling device in thermal ? Of
course for max665x to work, it would have to be modified to use
`devm_hwmon_device_register_with_info` instead of
`devm_hwmon_device_register_with_groups`

Another possiblity would be to create a new driver in drivers/thermal for
max665x as a thermal cooling device. Or even a
drivers/thermal/thermal-generic-hwmon-fan.c or something, where DTS would
instanciate such a cooling device which references a hwmon device's specific
pwm channel.

Phew! So many possibilities!

  reply	other threads:[~2019-04-18 19:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-18 16:48 [PATCH v2] hwmon: max6650: add thermal cooling device capability Jean-Francois Dagenais
2019-04-18 17:38 ` Guenter Roeck
2019-04-18 18:02   ` Jean-Francois Dagenais
2019-04-18 18:06     ` Guenter Roeck
2019-04-18 19:54       ` Jean-Francois Dagenais [this message]
2019-04-18 20:04         ` [PATCH v3] " Jean-Francois Dagenais
2019-04-18 20:13           ` Guenter Roeck
2019-04-18 20:45             ` Jean-Francois Dagenais
2019-04-18 20:55               ` Guenter Roeck
2019-04-18 20:12         ` [PATCH v2] " Guenter Roeck
2019-04-18 20:39           ` Jean-Francois Dagenais
2019-04-18 20:50             ` Guenter Roeck
2019-04-18 21:33               ` Jean-Francois Dagenais
2019-04-18 22:02                 ` Guenter Roeck
2019-04-19  0:57                   ` [PATCH v4] " Jean-Francois Dagenais

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=40DEF6F9-FA5B-4537-BD02-6763D7C885A1@gmail.com \
    --to=jeff.dagenais@gmail.com \
    --cc=jdelvare@suse.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /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).