All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Ni <wni-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Eduardo Valentin <edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	MLongnecker-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
	swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org,
	mikko.perttunen-/1wQRMveznE@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH V7 09/12] thermal: tegra: add thermtrip function
Date: Wed, 16 Mar 2016 13:53:53 +0800	[thread overview]
Message-ID: <56E8F4F1.1060603@nvidia.com> (raw)
In-Reply-To: <20160315194929.GB26619-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>



On 2016年03月16日 03:49, Eduardo Valentin wrote:
> * PGP Signed by an unknown key
> 
> On Tue, Mar 15, 2016 at 05:12:12PM +0800, Wei Ni wrote:
>>
>>
>> On 2016年03月15日 03:16, Eduardo Valentin wrote:
>>>> Old Signed by an unknown key
>>>
>>> On Fri, Mar 11, 2016 at 11:11:12AM +0800, Wei Ni wrote:
>>>> Add support for hardware critical thermal limits to the
>>>> SOC_THERM driver. It use the Linux thermal framework to
>>>> create critical trip temp, and set it to SOC_THERM hardware.
>>>> If these limits are breached, the chip will reset, and if
>>>> appropriately configured, will turn off the PMIC.
>>>>
>>>> This support is critical for safe usage of the chip.
>>>>
>>>> Signed-off-by: Wei Ni <wni-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>> ---
>>>>  drivers/thermal/tegra/soctherm.c          | 166 +++++++++++++++++++++++++++++-
>>>>  drivers/thermal/tegra/soctherm.h          |   7 ++
>>>>  drivers/thermal/tegra/tegra124-soctherm.c |  24 +++++
>>>>  drivers/thermal/tegra/tegra210-soctherm.c |  24 +++++
>>>>  4 files changed, 216 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
>>>> index 02ac6d2e5a20..dbaab160baba 100644
>>>> --- a/drivers/thermal/tegra/soctherm.c
>>>> +++ b/drivers/thermal/tegra/soctherm.c
>>>> @@ -73,9 +73,14 @@
>>>>  #define REG_SET_MASK(r, m, v)	(((r) & ~(m)) | \
>>>>  				 (((v) & (m >> (ffs(m) - 1))) << (ffs(m) - 1)))
>>>>  
>>>> +static const int min_low_temp = -127000;
>>>> +static const int max_high_temp = 127000;
>>>> +
>>>>  struct tegra_thermctl_zone {
>>>>  	void __iomem *reg;
>>>> -	u32 mask;
>>>> +	struct device *dev;
>>>> +	struct thermal_zone_device *tz;
>>>
>>>
>>> Why not using tz->dev for the *dev above?
>>
>> The tz is thermal_zone_device, this structure doesn't have *dev.
>> It only have the member "struct device device;", but this device is created for
>> the thermal class, not this tegra_soctherm device.
>>
>>>
>>>> +	const struct tegra_tsensor_group *sg;
>>>>  };
>>>>  
>>>>  struct tegra_soctherm {
>>>> @@ -145,22 +150,158 @@ static int tegra_thermctl_get_temp(void *data, int *out_temp)
>>>>  	u32 val;
>>>>  
>>>>  	val = readl(zone->reg);
>>>> -	val = REG_GET_MASK(val, zone->mask);
>>>> +	val = REG_GET_MASK(val, zone->sg->sensor_temp_mask);
>>>>  	*out_temp = translate_temp(val);
>>>>  
>>>>  	return 0;
>>>>  }
>>>>  
>>>> +static int
>>>> +thermtrip_program(struct device *dev, const struct tegra_tsensor_group *sg,
>>>> +		  int trip_temp);
>>>> +
>>>> +static int tegra_thermctl_set_trip_temp(void *data, int trip, int temp)
>>>> +{
>>>> +	struct tegra_thermctl_zone *zone = data;
>>>> +	struct thermal_zone_device *tz = zone->tz;
>>>> +	const struct tegra_tsensor_group *sg = zone->sg;
>>>> +	struct device *dev = zone->dev;
>>>> +	enum thermal_trip_type type;
>>>> +	int ret;
>>>> +
>>>> +	if (!tz)
>>>> +		return -EINVAL;
>>>
>>>
>>> Is the above check needed? If you saw a case in which your function is
>>> called without tz, would it be the case we have a but in the probe (or
>>> even worse, in thermal-core)?
>>
>> This tz isn't from thermal-core, it's from the "void *data".
>> This *data is the private structure "struct tegra_thermctl_zone *zone = data;".
>> It is registered in devm_thermal_zone_of_sensor_register(*dev, sensor_id, *data,
>> *ops). And when it register successful, I will set zone->tz = z, in here, the
>> zone is the private data.
>> Let's consider a special case, once the thermal_zone_of_sensor_register
>> successful and didn't run to "zone->tz = z" yet, then the thermal_core implement
>> .set_trip(), then it may cause problems in here, although it's difficult to hit
>> this case. So I think we need to do this check.
> 
> 
> Can you be more specific? I don't recall a case that core would call any
> driver callbacks before setting up the data structures properly.

Sorry for the confusion, I mean this data structure is the private data pointer,
it doesn't handled by thermal_core. Let me explain more:
In this tegra soctherm driver, I run following steps in probe routine:
step1:
z = devm_thermal_zone_of_sensor_register(*dev, sensor_id, zone, ops);
register thermal zone device, in here, the parameter "zone" is the private data
pointer "structure tegra_thermctl_zone".
step 2:
After register, it return the "z", and I set it to the private data:
zone->tz = z;

In the .set_trip() callback, it will pass back this private data pointer.
So if the callback was called between step1 and step2, at that time the zone->tz
didn't be set yet, it will cause problems, although I didn't hit this case.

This check doesn't relate with core driver, it is used to check my private data
pointer.

Wei.

> 
>>>
> 
> * Unknown Key
> * 0x7DA4E256
> 

WARNING: multiple messages have this Message-ID (diff)
From: Wei Ni <wni@nvidia.com>
To: Eduardo Valentin <edubezval@gmail.com>
Cc: <rui.zhang@intel.com>, <thierry.reding@gmail.com>,
	<MLongnecker@nvidia.com>, <swarren@wwwdotorg.org>,
	<mikko.perttunen@kapsi.fi>, <linux-tegra@vger.kernel.org>,
	<linux-pm@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V7 09/12] thermal: tegra: add thermtrip function
Date: Wed, 16 Mar 2016 13:53:53 +0800	[thread overview]
Message-ID: <56E8F4F1.1060603@nvidia.com> (raw)
In-Reply-To: <20160315194929.GB26619@localhost.localdomain>



On 2016年03月16日 03:49, Eduardo Valentin wrote:
> * PGP Signed by an unknown key
> 
> On Tue, Mar 15, 2016 at 05:12:12PM +0800, Wei Ni wrote:
>>
>>
>> On 2016年03月15日 03:16, Eduardo Valentin wrote:
>>>> Old Signed by an unknown key
>>>
>>> On Fri, Mar 11, 2016 at 11:11:12AM +0800, Wei Ni wrote:
>>>> Add support for hardware critical thermal limits to the
>>>> SOC_THERM driver. It use the Linux thermal framework to
>>>> create critical trip temp, and set it to SOC_THERM hardware.
>>>> If these limits are breached, the chip will reset, and if
>>>> appropriately configured, will turn off the PMIC.
>>>>
>>>> This support is critical for safe usage of the chip.
>>>>
>>>> Signed-off-by: Wei Ni <wni@nvidia.com>
>>>> ---
>>>>  drivers/thermal/tegra/soctherm.c          | 166 +++++++++++++++++++++++++++++-
>>>>  drivers/thermal/tegra/soctherm.h          |   7 ++
>>>>  drivers/thermal/tegra/tegra124-soctherm.c |  24 +++++
>>>>  drivers/thermal/tegra/tegra210-soctherm.c |  24 +++++
>>>>  4 files changed, 216 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
>>>> index 02ac6d2e5a20..dbaab160baba 100644
>>>> --- a/drivers/thermal/tegra/soctherm.c
>>>> +++ b/drivers/thermal/tegra/soctherm.c
>>>> @@ -73,9 +73,14 @@
>>>>  #define REG_SET_MASK(r, m, v)	(((r) & ~(m)) | \
>>>>  				 (((v) & (m >> (ffs(m) - 1))) << (ffs(m) - 1)))
>>>>  
>>>> +static const int min_low_temp = -127000;
>>>> +static const int max_high_temp = 127000;
>>>> +
>>>>  struct tegra_thermctl_zone {
>>>>  	void __iomem *reg;
>>>> -	u32 mask;
>>>> +	struct device *dev;
>>>> +	struct thermal_zone_device *tz;
>>>
>>>
>>> Why not using tz->dev for the *dev above?
>>
>> The tz is thermal_zone_device, this structure doesn't have *dev.
>> It only have the member "struct device device;", but this device is created for
>> the thermal class, not this tegra_soctherm device.
>>
>>>
>>>> +	const struct tegra_tsensor_group *sg;
>>>>  };
>>>>  
>>>>  struct tegra_soctherm {
>>>> @@ -145,22 +150,158 @@ static int tegra_thermctl_get_temp(void *data, int *out_temp)
>>>>  	u32 val;
>>>>  
>>>>  	val = readl(zone->reg);
>>>> -	val = REG_GET_MASK(val, zone->mask);
>>>> +	val = REG_GET_MASK(val, zone->sg->sensor_temp_mask);
>>>>  	*out_temp = translate_temp(val);
>>>>  
>>>>  	return 0;
>>>>  }
>>>>  
>>>> +static int
>>>> +thermtrip_program(struct device *dev, const struct tegra_tsensor_group *sg,
>>>> +		  int trip_temp);
>>>> +
>>>> +static int tegra_thermctl_set_trip_temp(void *data, int trip, int temp)
>>>> +{
>>>> +	struct tegra_thermctl_zone *zone = data;
>>>> +	struct thermal_zone_device *tz = zone->tz;
>>>> +	const struct tegra_tsensor_group *sg = zone->sg;
>>>> +	struct device *dev = zone->dev;
>>>> +	enum thermal_trip_type type;
>>>> +	int ret;
>>>> +
>>>> +	if (!tz)
>>>> +		return -EINVAL;
>>>
>>>
>>> Is the above check needed? If you saw a case in which your function is
>>> called without tz, would it be the case we have a but in the probe (or
>>> even worse, in thermal-core)?
>>
>> This tz isn't from thermal-core, it's from the "void *data".
>> This *data is the private structure "struct tegra_thermctl_zone *zone = data;".
>> It is registered in devm_thermal_zone_of_sensor_register(*dev, sensor_id, *data,
>> *ops). And when it register successful, I will set zone->tz = z, in here, the
>> zone is the private data.
>> Let's consider a special case, once the thermal_zone_of_sensor_register
>> successful and didn't run to "zone->tz = z" yet, then the thermal_core implement
>> .set_trip(), then it may cause problems in here, although it's difficult to hit
>> this case. So I think we need to do this check.
> 
> 
> Can you be more specific? I don't recall a case that core would call any
> driver callbacks before setting up the data structures properly.

Sorry for the confusion, I mean this data structure is the private data pointer,
it doesn't handled by thermal_core. Let me explain more:
In this tegra soctherm driver, I run following steps in probe routine:
step1:
z = devm_thermal_zone_of_sensor_register(*dev, sensor_id, zone, ops);
register thermal zone device, in here, the parameter "zone" is the private data
pointer "structure tegra_thermctl_zone".
step 2:
After register, it return the "z", and I set it to the private data:
zone->tz = z;

In the .set_trip() callback, it will pass back this private data pointer.
So if the callback was called between step1 and step2, at that time the zone->tz
didn't be set yet, it will cause problems, although I didn't hit this case.

This check doesn't relate with core driver, it is used to check my private data
pointer.

Wei.

> 
>>>
> 
> * Unknown Key
> * 0x7DA4E256
> 

  parent reply	other threads:[~2016-03-16  5:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-11  3:11 [PATCH V7 09/12] thermal: tegra: add thermtrip function Wei Ni
2016-03-11  3:11 ` Wei Ni
2016-03-14 19:16 ` Eduardo Valentin
     [not found]   ` <20160314191637.GC1872-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2016-03-15  9:12     ` Wei Ni
2016-03-15  9:12       ` Wei Ni
     [not found]       ` <56E7D1EC.5090907-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-03-15 19:49         ` Eduardo Valentin
2016-03-15 19:49           ` Eduardo Valentin
     [not found]           ` <20160315194929.GB26619-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2016-03-16  5:53             ` Wei Ni [this message]
2016-03-16  5:53               ` 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=56E8F4F1.1060603@nvidia.com \
    --to=wni-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
    --cc=MLongnecker-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mikko.perttunen-/1wQRMveznE@public.gmane.org \
    --cc=rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.