linux-kernel - Re: [PATCH 3/3] thermal: of: notify sensor driver on trip updates

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 1 Dec 2014 12:45:52 -0800
From:	navneet kumar <navneetk@...dia.com>
To:	Eduardo Valentin <edubezval@...il.com>
CC:	<rui.zhang@...el.com>, <linux-pm@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] thermal: of: notify sensor driver on trip updates

Hi Eduardo,

On 11/27/2014 06:32 AM, Eduardo Valentin wrote:
> * PGP Signed by an unknown key
> 
> Hello Navneet,
> 
> On Wed, Nov 26, 2014 at 05:16:29PM -0800, Navneet Kumar wrote:
>> From: navneet kumar <navneetk@...dia.com>
>>
>> some thermal sensor hardwares include logic which
>> can raise interrupts at certain programmed temperature
>> thresholds.
>>
>> Drivers for such sensors should be able to learn the
>> appropriate threshold temperatures for interrupts by querying
>> the thermal framework.
>>
>> This change provides a mechanism to allow a sensor driver to
>> update it's thresholds when userspace changes a trip point
>> temperature.
>>
>> While this behavior may not make sense in thermal zones
>> with more than one sensor, no such examples exist in
>> the kernel.
>>
>> Signed-off-by: navneet kumar <navneetk@...dia.com>
>> ---
>>  drivers/thermal/of-thermal.c | 7 +++++++
>>  include/linux/thermal.h      | 1 +
>>  2 files changed, 8 insertions(+)
>>
>> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
>> index 3d47a0cf3825..3568e4a586dc 100644
>> --- a/drivers/thermal/of-thermal.c
>> +++ b/drivers/thermal/of-thermal.c
>> @@ -258,6 +258,9 @@ static int of_thermal_set_trip_temp(struct thermal_zone_device *tz, int trip,
>>  	/* thermal framework should take care of data->mask & (1 << trip) */
>>  	data->trips[trip].temperature = temp;
>>  
>> +	if (data->sops.trip_update)
>> +		data->sops.trip_update(data->sensor_data, trip);
>> +
>>  	return 0;
>>  }
>>  
>> @@ -285,6 +288,9 @@ static int of_thermal_set_trip_hyst(struct thermal_zone_device *tz, int trip,
>>  	/* thermal framework should take care of data->mask & (1 << trip) */
>>  	data->trips[trip].hysteresis = hyst;
>>  
>> +	if (data->sops.trip_update)
>> +		data->sops.trip_update(data->sensor_data, trip);
>> +
>>  	return 0;
>>  }
>>  
>> @@ -500,6 +506,7 @@ void thermal_zone_of_sensor_unregister(struct device *dev,
>>  
>>  	tz->sops.get_temp = NULL;
>>  	tz->sops.get_trend = NULL;
>> +	tz->sops.trip_update = NULL;
>>  	tz->sensor_data = NULL;
>>  	mutex_unlock(&tzd->lock);
>>  }
>> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
>> index 58341c56a01f..b93e65815175 100644
>> --- a/include/linux/thermal.h
>> +++ b/include/linux/thermal.h
>> @@ -292,6 +292,7 @@ struct thermal_genl_event {
>>  struct thermal_of_sensor_ops {
>>  	int (*get_temp)(void *, long *);
>>  	int (*get_trend)(void *, long *);
>> +	int (*trip_update)(void *, int);
> 
> First thing I ask you is to update your work on top of my -linus branch,
> as I already mentioned. Reasoning is that part of the changes you are
> sending is already there.
will do.
> 
> As for this new callback, I am fine with it as long as it is also
> available for drivers that do not use of-thermal. Once again, of-thermal
> is not a competitor of thermal core. It will never be. It is not a new
> thermal API. 
I agree that this callback is not a part of the thermal_core functionality.
However, when a driver registers directly with the thermal_core (doesn't use
of-thermal), it 'owns' the set_trip_XX callbacks in the first place; which is
the sole purpose of using the 'trip_update' callback in of-thermal.

Adding an additional 'update' to the thermal_core ops would be a no-op. right?
> 
> That said, it does not make sense to have functionality in of-thermal that
> do not belong to thermal core. Exceptions are, of course, for helping
> doing the same operations we already have in thermal core.
> 
> All the best,
> 
> Eduardo Valentin
> 
>>  };
>>  
>>  /* Function declarations */
>> -- 
>> 1.8.1.5
>>
> 
> * Unknown Key
> * 0x7DA4E256
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/