linux-renesas-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@gmail.com>
To: Eduardo Valentin <edubezval@gmail.com>
Cc: linux-pm@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Zhang Rui <rui.zhang@intel.com>,
	Marek Vasut <marek.vasut+renesas@gmail.com>
Subject: Re: [PATCH V3 3/6] thermal: Register hwmon in thermal_zone_of_sensor_register_param()
Date: Mon, 11 Feb 2019 20:29:34 +0100	[thread overview]
Message-ID: <1b331713-d1d1-1fe0-277e-2fea4866c244@gmail.com> (raw)
In-Reply-To: <20190205232442.GA4423@localhost.localdomain>

On 2/6/19 12:24 AM, Eduardo Valentin wrote:
> On Mon, Jan 28, 2019 at 01:10:11PM +0100, Marek Vasut wrote:
>> On 1/15/19 1:35 AM, Marek Vasut wrote:
>>> On 12/22/18 3:19 AM, Marek Vasut wrote:
>>>> On 12/18/2018 10:44 PM, Eduardo Valentin wrote:
>>>>> On Mon, Dec 17, 2018 at 04:56:41PM +0100, marek.vasut@gmail.com wrote:
>>>>>> From: Marek Vasut <marek.vasut@gmail.com>
>>>>>>
>>>>>> Register hwmon sysfs interface in thermal_zone_of_sensor_register_param()
>>>>>> in case thermal_zone_params->no_hwmon is set to false. This behavior is
>>>>>> the same as thermal_zone_device_register().
>>>>>>
>>>>>> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>>>>>> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>>>> Cc: Eduardo Valentin <edubezval@gmail.com>
>>>>>> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
>>>>>> Cc: Zhang Rui <rui.zhang@intel.com>
>>>>>> Cc: linux-renesas-soc@vger.kernel.org
>>>>>> To: linux-pm@vger.kernel.org
>>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>>>>>> ---
>>>>>> V2: No change
>>>>>> V3: - Work around the From line and SoB line checkpatch warning
>>>>>>     - Reorder the SoB line at the end
>>>>>> ---
>>>>>>  drivers/thermal/of-thermal.c | 12 +++++++++++-
>>>>>>  1 file changed, 11 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
>>>>>> index e1a303a5698c..5ccff7b678de 100644
>>>>>> --- a/drivers/thermal/of-thermal.c
>>>>>> +++ b/drivers/thermal/of-thermal.c
>>>>>> @@ -15,6 +15,7 @@
>>>>>>  #include <linux/string.h>
>>>>>>  
>>>>>>  #include "thermal_core.h"
>>>>>> +#include "thermal_hwmon.h"
>>>>>>  
>>>>>>  /***   Private data structures to represent thermal device tree data ***/
>>>>>>  
>>>>>> @@ -521,8 +522,15 @@ thermal_zone_of_sensor_register_params(struct device *dev, int sensor_id,
>>>>>>  		if (sensor_specs.np == sensor_np && id == sensor_id) {
>>>>>>  			tzd = thermal_zone_of_add_sensor(child, sensor_np,
>>>>>>  							 data, ops);
>>>>>> -			if (!IS_ERR(tzd))
>>>>>> +			if (!IS_ERR(tzd)) {
>>>>>> +				tzd->tzp = tzp;
>>>>>
>>>>> So, here you will overwrite what was done in of_parse_thermal_zones().
>>>>> That means, after this point, property like sustainable power, slope and
>>>>> offset are gone.
>>>>
>>>> Hmmmmm, that was rather inobvious, indeed.
>>>>
>>>> Do you have some suggestion how to pass in the no_hwmon = false then ?
>>>> Since tzp->no_hwmon is set to true in of_parse_thermal_zones(), the
>>>> three drivers (stm32, rcar, rcar_gen3) seem to hack around it. I'd like
>>>> to clean that up.
>>>
> 
> Yeah, that is an issue.
> 
>>> Bump ?
>>
>> Bump again, any suggestions ?
> 
> Yeah, a couple of ideas have been proposed for this issue.
> 
> First most tempting one is to have a DT property per thermal zone.
> Making it linux specific, something prefixed by linux,<property>. I
> recall Amit Kutcheria trying something similar to this, but dont
> remember where that went. Frankly, this is a Linux thing, I am not
> convinced DT is really the right place to fix this.

DT is not the right place for this, DT describes hardware and this is
policy, so it shouldn't be in DT.

> Another hack that could be written is a module parameter for of-thermal
> that would reflect the no_hwmon value, globally. The down side here is
> you have to make sure all drivers match that no_hwmon value, right?

Indeed, it should be the driver which decides whether or not to register
a HWMON interface for the thermal zone.

I guess for now, I'll just discard this entire series and hack the data
structure like other drivers do, since I don't see any reasonable solution.

-- 
Best regards,
Marek Vasut

  reply	other threads:[~2019-02-11 19:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-17 15:56 [PATCH V3 0/6] thermal: Align devm_thermal_zone_{device,of_sensor}_register marek.vasut
2018-12-17 15:56 ` [PATCH V3 1/6] thermal: split thermal_zone_of_sensor_register{,_param}() marek.vasut
2018-12-18 11:04   ` Simon Horman
2018-12-17 15:56 ` [PATCH V3 2/6] thermal: split devm_thermal_zone_of_sensor_register{,_param}() marek.vasut
2018-12-18 11:04   ` Simon Horman
2018-12-17 15:56 ` [PATCH V3 3/6] thermal: Register hwmon in thermal_zone_of_sensor_register_param() marek.vasut
2018-12-17 18:12   ` Wolfram Sang
2018-12-22  2:16     ` Marek Vasut
2018-12-18 11:04   ` Simon Horman
2018-12-18 21:44   ` Eduardo Valentin
2018-12-22  2:19     ` Marek Vasut
2019-01-15  0:35       ` Marek Vasut
2019-01-28 12:10         ` Marek Vasut
2019-02-05 23:24           ` Eduardo Valentin
2019-02-11 19:29             ` Marek Vasut [this message]
2019-02-12  8:52               ` Geert Uytterhoeven
2019-02-12 16:12                 ` Guenter Roeck
2018-12-17 15:56 ` [PATCH V3 4/6] thermal: stm32: Convert to devm_thermal_zone_of_sensor_register_params() marek.vasut
2018-12-18 11:05   ` Simon Horman
2018-12-17 15:56 ` [PATCH V3 5/6] thermal: rcar_thermal: " marek.vasut
2018-12-18 11:05   ` Simon Horman
2018-12-19 23:25     ` Marek Vasut
2018-12-20  7:46       ` Simon Horman
2018-12-20 23:13         ` Marek Vasut
2018-12-17 15:56 ` [PATCH V3 6/6] thermal: rcar_gen3_thermal: Register hwmon sysfs interface marek.vasut
2018-12-18 11:06   ` Simon Horman

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=1b331713-d1d1-1fe0-277e-2fea4866c244@gmail.com \
    --to=marek.vasut@gmail.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=edubezval@gmail.com \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=marek.vasut+renesas@gmail.com \
    --cc=rui.zhang@intel.com \
    --cc=wsa+renesas@sang-engineering.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).